Как программисту оценить и увеличить темп работы

Медленно пишете код? Руководство считает, что можете работать в два раза быстрее? Завидуете коллегам, оперативно решающим задачи? Действительно ли у вас низкая производительность? Оценить свой темп работы и увеличить его вы сможете, используя простые советы из данной статьи.

 

Выявите проблему

Скорость написания кода — параметр весьма субъективный. Хотя бы с той точки зрения, что ощущение разработчика о том, что он медленно создает продукт, может носить как временный, так и постоянный характер. В первом случае речь идет о ситуации, когда программист не в состоянии прямо сейчас написать код.

Причины могут быть разные:

  1. Не хватает базовых знаний, чтобы понимать слово или символ.
  2. Нет возможности удержать все идеи для решения задачи в голове.
  3. Не знаете с чего начать.
  4. Пропущены шаги разработки.
  5. Существуют отвлекающие факторы.

В результате получаем несоблюдение дедлайна, проваленный проект, лишение премии и другие неприятности. По мере накопления негативного опыта «медленного» решения задач возникает ощущение низкой производительности.

А выговоры руководства за несоблюдение сроков и порицание от коллег, которых вы подвели, лишь усиливают это чувство. Учитывая нынешнюю ситуацию в IT-сфере, не трудно догадаться, что компания в первую очередь расстанется с «опаздунами».

 

Используйте готовые решения

Существует возможность не только форсировать решение конкретной задачи, но и в целом увеличить скорость работы.

Разберем по пунктам, что делать, если проблема носит локальный характер:

  1. В случае пробелов в базовых знаниях — обратитесь к старшим коллегам либо профессиональному сообществу в сети за помощью.
  2. Если не можете представить всю архитектуру задачи целиком — запишите или нарисуйте решение на бумаге.
  3. Если нет идеи, с чего начать — сделайте часть задачи, для которой у вас есть решение, даже если это не самая важная функция.
  4. Чтобы не пропустить шаги разработки — составьте план, разбейте код на простые элементы, идущие в определенном порядке.
  5. Если вы часто отвлекаетесь — разделите задачу на элементарные подзадачи. Работайте итерациями по 25-30 минут с 5-минутными перерывами. Именно столько времени специалист может целиком фокусироваться на решении несложной задачи.

 

Увеличьте скорость разработки

Что же делать, если у вас уже сформировалось устойчивое мнение о своей низкой производительности? В этом случае нужно правильно оценить скорость решения задач. Для этого сравните свои нижеперечисленные показатели и коллег:

  • скорость написания кода;
  • его качество;
  • сопровождение;
  • читаемость;
  • обилие комментариев.

Сделать это непросто, задачи, как правило, различаются, поэтому делайте выборку из 10-15 задач. В результате наблюдения и анализа вы сможете оценить свою скорость разработки.

Если она вас не устраивает — обратитесь к старшим разработчикам, которые объяснят, что надо сделать, чтобы ускориться. Если же, допустим, вы один программист в компании и работаете на конкретном стеке. В этом случае вы не можете сравнить производительность свою и коллег. Здесь вам поможет общение с профессиональным сообществом. В настоящее время для каждого стека существует своя группа программистов в Slack. Рассказывайте о личном опыте, просите содействия в решении проблем. Продемонстрируйте свой вариант решения задачи, расскажите, сколько времени на это потребовалось. Узнайте, сколько времени тратит на такое решение в среднем разработчик.

 

Применяйте программы для учета времени

 

Вы можете оценивать скорость своей работы, опираясь на внутренние ощущения, если уже имеете солидный опыт программирования.

Например: « Мне нужно закодить модель, реализовать API из 10 методов, а я все еще пакет utils наполняю».

Новичок скорее будет себя сравнивать с коллегами:

«Андрей вот уже три отчета поправил, а я со вторым не могу разобраться».

Все это весьма приблизительные способы оценки своего темпа работы, которые не позволяют прикинуть, сколько времени вы тратите на конкретную задачу. Для объективной оценки используйте программы, дающие возможность фиксировать тайминг по задачам и время на их уточнение.

Благодаря полезному функционалу вы сможете:

  • Показать руководству, сколько времени ушло на конкретную задачу. Это даст им ясную картину по вашей загрузке. Порой администрация имеет лишь отдаленное понятие, насколько загружен сотрудник и сколько времени у него уходит на уточнение некорректно поставленной задачи.
  • Сравнить затраченное время на однотипных задачах сейчас, на прошлой неделе, месяце и году. Если темп ваш увеличивается и качество продукта растет, значит, вы двигаетесь в правильном направлении. Демонстрируя реальные цифры, можно смело просить прибавку к зарплате у руководства.
  • Показывая свой код сообществу профессионалов, вы можете сказать, что написали этот код за пять часов и узнать, нормально ли это. И, опираясь на обратную связь, оценивайте свой темп работы.

 

Добивайтесь поставленных целей

Независимо от потребностей, которые стоят за целью писать код быстрее — соблюдать дедлайн, повысить зарплату, обеспечить карьерный рост или сохранить работу — вы можете использовать все данные наработки или выбрать конкретно те, которые помогут вам повысить темп своей работы.

 

Читайте новости первыми в нашем Telegram-канале!

Подписывайтесь на наш канал в Дзен!

Версия для печатиВерсия для печати

Рубрики: 

  • 1
  • 2
  • 3
  • 4
  • 5
Всего голосов: 0
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!

Комментарии

Аватар пользователя mike

Знаю только 1 (один) способ: постоянно думать о своей задаче. Тогда и декомпозиция сама собой, и в сроки уложишься, и впишешься в задачу команды. Остальное, считаю, - - бла-бла-бла от любителей гонораров за незамысловатый клавотык.

:) 

+1

Если программист не знает как выполнить свою работу, то это и не программист вовсе. Студент разве что. И сама цель быстро написать программу идиотизм. Это же не лабораторные здавать, там да надо быстро. Если делать быстро, то будет много ошибок и недостатков, будет непонятный интерфейс. А это надо будет исправлять, на это уйдёт время. В результате получится опять медленно. Лучше с самого начала ко всему подходить основательно, да будет медленней, зато без ошибок, согласно ТЗ, и понятным пользователю интерфейсом. Как говарят в Японии, быстро, это тоже самое что медленно, только без перерывов.