or maybe you do, I don’t know

Shared state sucks

Look at this example:

This code sucks for a lot of reasons. For example, have you noticed a bug in method? It is there, and the reason is a shared state.

Now every method can use all four shared variables. Even more, methods can change the values of the variables or add more variables! It sounds crazy, but you can see a lot of cases like that in real projects.

This class has several problems. Now I want to talk about the essence of every class: its shared state. It is there, it’s mutable, and it makes code…


Here are some tips I use to provide better naming for functions I write.

Don’t use save/load without to/from

is a nice name; is not. The same thing goes with and .

If you have multiple data storages, a function call doesn’t tell you which one you are using. You have to ctrl-click it. Every. Damn. Time.

Use test_<entity>_<behavior> template for tests names

Say we are writing a unit test to a function called . Here are some bad test names: , , , . And these names look nice and informative: , , .

Important note on the behaviour part: it should say what exactly we are…


The Motivation Part

Well, we all know that clear naming is crucial for readability.

Still, I see a function named in every project. I renamed it to in one project and to in another. As you can see, the functions had the same name but had nothing in common.

The most important part of a function name is a verb. The most popular verb is “get”, and it is a very lazy choice: it gives us none of the additional info. For example, you can replace “get” with “fetch”, then I would know that the function receives data from the network/disk.


Представляю вам Кодекс работы с фидбеком (джуниорский).

Не бездействуйте, если что-то не так.

Говно накапливается и взрывается, если его не вычищать. Даже если вас бесит какая-то мелочь — скажите.

Даёте фидбек — говорите спокойно, не выёбывайтесь.

Вы ведь даёте обратную связь ради того, чтобы собеседник перестал вести себя плохо и начал вести себя хорошо. Если вы его отхуесосите, он будет хуесосить вас, а не вести себя хорошо.

Принимаете фидбек — не говнитесь.

Ваш собеседник ведь не просто так его даёт, там под капотом наверняка есть какой-то ваш косяк. Не бомбите, постарайтесь докопаться до сути.


Представляю вам Теорию О Новых Граблях: опыт прямо пропорционален количеству разных собранных граблей, а общее количество граблей в единицу времени ограничено.

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

К тому же если вы допускаете одни и те же ошибки, с вами сложно работать. Ну вы знаете вот это вот “ну мы же уже обсуждали, что…”. В общем, это довольно большой урон для вас как профессионала.

Наконец, повторение одних и тех же косяков приводит к тому, что вы сами демотивируетесь: видите же, что…


В этой заметке я буду обсасывать мысль о том, что для нормального самообучения вам нужно не просто курсики на Курсере смотреть, а составить долгосрочный план развития, проанализировать основные компетенции, оценить, спланировать, заложить бабла и времени и только потом начинать. “Кем вы видите себя через пять лет”, вот это вот всё.

Проблема реактивного обучения в том, что оно часто размывает область знаний. Увидел интересный курс — записался, прошёл. Увидел ещё один–прошёл и его. Поигрался с той технологией. Почитал про новый подход. В итоге узнал какую-то разрозненную кучу информации, которая далеко не вся пригодится в ближайшие годы. Не самый рациональный расход времени.


Работа с джуниор-разработчиками — это отдельная песня. Такая работа больше похожа на обучение, чем на работу, особенно в начале.

Получается, что важно грамотно выстроить это обучение: подобрать правильные задачи, подходящие материалы, тратить время на ревью и всё такое.

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

Бывает, что разработчик задаёт десяток вопросов каждые пять минут. На один из них ему скорее всего уже отвечали, ещё в трёх он не знает, чего сам спрашивает, ответы на пять можно легко нагуглить. С…


Не работайте больше положенного. Ниже несколько причин для этого.

Вы непродуктивны когда не выспались

История стара как мир: интересная задача или горящий дедлайн уговаривают вас посидеть за работой ночером. Вы, само собой, позже ложитесь спать и меньше спите. Не сильно, часа на 2–3. Ну может 4.

Вашей производительности на следующий день пизда. Вопрос только в её масштабе: вы можете весь день ходить сонным и тормозить, а можете даже не замечать, что что-то не так, но не подумайте, что всё ок. Даже в этом случае вы работаете не так продуктивно, как обычно.

По моему опыту этот просёр в производительности не стоит бонуса в рабочем времени, который…


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

Я не считаю, что неопытность является оправданием в том, чтобы не выполнить какую-то договорённость. Поэтому для начинающего разработчика это так же важно, как и для сеньёра: обычно выполнение подобных договорённостей — не вопрос опыта, а вопрос системного подхода и серьёзного отношения к работе.

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


Давайте поговорим про стиль кода.

Вот моя заметка о том, что это такое и зачем оно нужно. С неё можно начать.

Самое главное, что мне хочется тут обсудить — это ощущение “да блин, это всё какое-то задротство”. Когда в первый раз сталкиваешься с таким количеством кода для проверки “основного” кода, кажется, что это неоптимальный расход времени и вообще блажь того, кто за это отвечает.

Это не так. Чем больше мы заложим на это времени на старте и в процессе работы, тем больше пользы мы получим через год-два-пять существования проекта и это очень выгодные вложения.

Да, для этого придётся тратить время…

Ilya Lebedev

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store