Soft skills для IT-специалистов. Прокачай карьеру и получи работу мечты

Наши стандарты кодирования были разработаны в другое время и в другом месте. Первоначально целью было сделать код более читаемым, поэтому стандарты были сосредоточены на соглашениях об именовании переменных и функций. Со временем мы разработали базовые стандарты модулей, чтобы попытаться избежать увеличения кода, с которым столкнулись в его некоторых важных частях. Но тогда мы все использовали один и тот же язык программирования – C#. Сегодня организация превратилась в настоящего полиглота с большой кодовой базой C#, JavaScript и растущей кодовой базой Python в командах инженеров DevOps. Стандарты кодирования, которые мы изначально разработали, более не могут эффективно масштабироваться на эти языки, и попытки поддерживать их замедляют нас и создают враждебность между командами. Я полагаю, что пришло время переосмыслить цель стандартов кодирования, какую ценность они приносят и как мы ее достигаем в нынешних условиях. Вместо подхода «сверху вниз», который мы использовали в прошлом, я предполагаю, нам подойдет более совместный подход, который позволил бы каждому работнику и команде принять участие в обсуждении.

На ваш взгляд, как хорошо написан этот отрывок? Потратьте несколько минут на его изучение. Заметили формулировку «были разработаны» в первом предложении?

Это пассивный залог; непонятно, кто разработал стандарты. Я бы переписал это предложение в более ясной и прямой форме, убрав пассивный залог, например: «Мы разработали наши стандарты кодирования в другое время и в другом месте». Если вы не понимаете, о чем я говорю, не волнуйтесь, скоро я расскажу о пассивном залоге и его пугающем влиянии на текст.

На самом деле на данном этапе это единственное, за что можно критиковать этот текст. В конце концов, мы не знаем, кто слушатель, не знаем, какой контекст уже есть у аудитории. Уместно ли начать обсуждение с истории возникновения стандартов кодирования? Возможно, если у аудитории нет такой истории. Но если они ее знают, то повтор может оказаться пустой тратой времени. Дело в том, что коммуникация должна быть рассчитана на определенную аудиторию. Вы когда-нибудь сидели на собрании, где только и делали, что бубнили о том, что вы и так уже знаете? Вот вам и пример неверно структурированной истории.

Помимо этого, структуру моего примера можно немного улучшить. Наряду с акцентом на классическую сюжетную структуру путешествия героя, эффективное письменное общение следует подходу «проблема-контекст-решение», и вот как это выглядит: