Cycles, Life & Death

Everyone is different; all of us mutate slightly in different ways, and we don’t all come out identical—well, at least most humans don’t. This bundle of differences is called humanity. I guess that’s what makes it fun—a randomness factor. For some reason, I’ve never liked cycles. In a way, cycles annoy me. The irony is that over time I started to embrace routine, but not for the sake of it, but rather due to an aging body.

20 years ago, I got a gig at a car parts factory, working the night shift, packing plastic parts and cleaning floors when it was slow. The job sucked; I didn’t like working nights and going to sleep when everyone was out and about. But what bothered me the most was the job itself—the endless repetition of the same steps, over and over again, all night long and the next night and the next. It seemed like an endless cycle of doing exactly the same things over and over again.

Although I enjoy video games, the reason I don’t tend to play a lot (besides not having enough free time) is the repetitive cycle. Yes, different cycles and repetitions with a different combination of red, green, and blue on the screen, yet with sufficiently different cycles to get me bored or annoyed. There are only so many times I can go on a quest to kill 10 boars or whichever virtual animal is demanded by a virtual quest giver. Now I’m not complaining about games; I do enjoy them—I played Diablo repeatedly—I just want to point out my own personal mutation for lack of a better word.

Life itself seems annoying; it is repetitive cycles with a different given at each new start. You are 10, so you need to do this and that. You made it to 20 – education time, 30 – family time, 40 – wealth gathering time, 50 – health…, 60 – retirement… and so on. The illustration is crude but has some merit to it. Does it have to go that way? Well… no. There are different ways life can be played or be played out. Hey, remember: “live fast, die young”? – it is a viable option too. If I had a choice, I would probably go to the other extreme; let’s do the whole life thing for a few hundred years and then decide.

Human time constraints seem to put us into well-defined, optimized, and seemingly inescapable cycles. Each cycle presents its challenges, and there’s never enough time. Ricardo Semler had an interesting idea about working less and spending more time on ourselves early on and not waiting for retirement when the body is broken and tired. His arguments and ideas were very convincing! As much as I would love to implement that, I do not live in theory; bills are due, time is running, and food should be on the table. So cycles continue… meanwhile, we miss moments, and before you know it, people near and dear start to die off.

Those endless cycles of being busy, accomplishing things that seem meaningless now. If only we had more time, more time to make educated choices, more time to figure out priorities, more experience to understand what’s important to ourselves. Perhaps one day we may get more time, but for now, the only thing is to dispense it conservatively.

2 Years Since the Full-Scale Invasion of Ukraine

It’s hard to believe it’s been 2 years since the full-scale invasion of Ukraine. I figured that after the initial shock, the West would ramp up military support and quickly deal with the occupiers. However, that didn’t happen. Moreover, Ukraine is once again at a crossroads, with Iran, North Korea, and China providing support/weapons to the occupiers, while Europe continues to drag its feet, and the USA has fallen into inaction. I think the world is learning from this, and the unfortunate lesson is: the West is perceived as weak and easily disrupted. As long as a dictator can hold out, lobby, and flood the media with disinformation at comparatively low costs, any kind of crime will go unpunished.

Last year, Ukraine performed a counter-offensive. While expectations were sky-high, the results were underwhelming. I can’t help but wonder: how exactly was Ukraine supposed to perform an overwhelming counter-offensive in the first place? Let me break down my confusion: first, the counter-offensive was heavily advertised as if it were some kind of Super Bowl commercial at the end of times. I really didn’t understand the purpose of that. Then, Western weapons were delayed but finally arrived:

  • About 14 British Challenger 2 tanks
  • About 31 American Abrams tanks (but downgraded in capability)
  • About 80 tanks provided by various countries were Leopard 2s
  • About 88 tanks provided by various countries were Leopard 1s

In total, slightly over 200 tanks, considering I didn’t mention other variations of the Leopard 2, and I don’t consider the French AMX-10 RC as a battle tank. There was no aviation, no ATACMS, and a limited supply of long-range missiles such as Storm Shadow (Germany is still withholding Taurus missiles). Now, the list of shortcomings can be continued, but the picture is quite clear: 200 tanks versus fortified defenses and a few thousand Soviet tanks. Does that make any sense? But what makes me laugh (sadly) is the fact that Ukraine seems to receive, in bulk, only old tanks — for example, the Leopard 1. Really? Yes, it was modified in the ’80s, but… 88 tanks that were designed in the late ’50s.

So, to sum up my confusion: we give Ukraine old equipment and/or modern equipment in limited quantities and expect overwhelming results? I don’t know how this computes in anyone’s head. I really hope there is a winning strategy and that the West will eventually start acting as if it means it.

What gives me hope is the Ukrainian people who continue fighting despite the overwhelming odds. While some are at the front, others bring supplies, build drones, design new equipment, and more. This makes me believe that, at the end of the day, the forces of light will prevail. Ukraine will defeat this horrible evil.


I’ve been to Israel a couple of times, each time enjoying the country in different ways. In the last 75 years of Israel’s history, it has managed to build itself literally from the ground up – from a desert into a modern country. This achievement is quite commendable and hard to imagine, especially when some countries with much longer histories and larger resources haven’t managed as well.

On the other hand, over the last 75 years, its neighbors have prioritized violence, murder, and terror. Can you imagine living your entire life thinking only of killing your neighbor? They say “freedom fighters,” but the last election in Gaza was 18 years ago – is that freedom? 75 years of the same – hatred, violence, terror. Kids are taught to hate, teens to kill, and adults to support a system that leads nowhere. Yet, judging by the news, some people around the world think it’s a good idea.

I guess people on the streets want to see what they want to see, so let me tell you what I saw. The last time in Jerusalem, I was carelessly walking through the old market. There were a bunch of shops where Arabs were hustling. I was standing outside one shop, looking down the street. My eyes met the eyes of a kid who was standing outside yet another shop. He looked at me directly and made a throat-cutting gesture with his finger.

Ukraine is fighting for 7 months now

Couple of days ago, putler announced “partial mobilization” of 300 thousand men. In reality it is a full mobilization and numbers looking towards a million. It is not a good news for Ukraine, but let’s not forget, at the beginning of the war, situation was much worse.

As I was thinking about the mobilization, I decided to find a trailer for a documentary and it brought back memories of how fearlessly and courageously Ukrainians fought and continuing to fight. Mobilization will not help putler, it will not save anyone or anything, just one more stop on the way to hell.

Premature optimization, value and waste

Ah, premature optimization, every developer sooner or later hits that. You optimize code, iron it out so there are no extra cycles, no extra memory or what not and not terribly long after you have to take that carefully tailored code apart, just because a new requirement came in. Worse yet, the realization that the optimization was useless in the grand scheme of the app, yes the app works more efficiently but it does not affect anything at all. Some might be proud of the craftsmanship, others might be disappointed with the waste, in any case I’m not here to judge.

I am here to share a story about premature optimization but at a much higher level – a feature level. A few years back when I started writing my app I wanted it to have a feature, let’s call it “frequency determinator”- feed data to the app and it can determine how often an event occurs. In my mind, it was very cool to feed the app data and automagically determine a pattern. Well, I started with the determinator code, it was simple but working. I said “great, it is time to apply it to real data that I have”. But there was a problem, I didn’t have an app, it was just code for frequency generation, I would like to be able to upload data from my phone and see the magic. Ok, no problem, I thought to myself, I just need an UI. I wrote first version of UI, which looked very basic and was incredibly confusing to use at times even to myself. So I rewrote it, added few features, just so the app can be a bit more useful to me. I thought to myself: “well, now that I have UI would it nice to have this and that, I’ll hook up frequency determinator in next little while”. I showed my app to a friend but UI was still confusing. Ok, no problem, I rewrote it again and added more features. Since I already had some data in the app, it was becoming more and more useful. Along the way I did some more refactoring, added just few more features, changed the UI a couple more times and the app was shaping up more and more. I was happy, the app alleviate big chunk of my anxiety and with each new feature, it was becoming more valuable and refined.

Is it there yet? Nope, I still need to rewrite the UI, since there is lot of room for improvement in usability. I can definitely use couple more features and some additional features that I believe can reduce some of my anxiety. So when is “frequency determinator” coming in? I don’t know! As I was using the app, refactoring and adding features, I gradually realized that time for “frequency determinator” hasn’t come yet. There is no need and from the feedback I got, it might not be ever needed. Something that looked like great feature, a centre piece of the jewel, turns out otherwise. Once you use the app, you realize where the value is for you. Once others use the app, you see move value around. The value doesn’t exist in vacuum of your own ideas, value only exists when someone points to it.

So, what now, stop wasting time and start looking for value? I wish I can say that but in reality my ideas of “frequency determinator” kicked started initial development. I might not have started writing the app without believe that “frequency determinator” will be the key to solving my problems. So is there a value in a waste? I believe there is, we “waste time” but because of it, we come up with ideas. I think wasting time looking at the sky or laying around on the coach is actually a good thing. But nothing will come out of waste alone, entertain ideas enough, build something, use it and see if the value is there for you.

Moving forward, Jobs and Morning routine

I figured to share few thoughts that been circulating in my brain for a while…

When you are looking for a job, don’t spam your resume to every possible site unless you are starting at ground zero. It is counter productive and might make things worse. You should be sending/applying to jobs/companies where you want to take your career or expand your knowledge. If you don’t have a list of companies, find a career marketplace with narrow focus, for example – marketplace for IT jobs (there are more out there). It is imperative to operate in simple yet effective cycles: understand if there is demand for your skills, find what you are lacking, learn it (at a basic level first) and apply, if nothing comes your way, repeat the cycle again. Some companies are looking for specialists, others willing to take a chance. Important note here is: if you are not investing into yourself, why would anyone else? Take special care for people and companies that are willing to give you feedback. Lack of feedback is the worst thing that can happen to you, yes worse than rejection! Without feedback you don’t now where to go and what to improve. Lack of feedback is very taxing mentally, you might feel worthless and that might lead into the more dangerous state of physically stopping to “moving forward”.

Learn to have a morning routine, when you take 20 minutes to learn. Why 20 minutes? Because it is more than 15 but less than 30 – it is a brain hack. The idea that “I’ll study on a weekend for a few hours” is a false one – it will not happen, trust me, it is proven empirically. If you are not use to studying for 20 minutes, you will NOT be studying once per week for a few hours – your brain is more inventive than you might suspect when it comes to “how to get out of this?”. Yes 20 minutes isn’t much but that’s starting point and you will be surprise how much stuff can be done in just 20 minutes of focused work. More over, 20 minutes every single day stacks up! You will be pleasantly surprised by the progress. Next, expand 20 minutes to whatever you can afford (25,30,40+). It is worth remembering that only you, yourself can increase your own value. Don’t expect companies to invest into you unless you are working at a good company. Even then the company will train you in whatever the company needs, which might not align with your own plans. Remember: if you don’t want to invest into yourself, why should anyone else invest into you?

Nazi Russia

Finally after several days of shock and dismay, I can write, just not sure what exactly to say. If you asked me a week ago: “would Russia attack Ukraine?” – I would have answered: “no way, never gonna happen!” – Obviously I was wrong. I’m not a history buff (also I’m not a professional writer so excuse my poor writing), but Russia’s action sure shit looks like Nazi Germany at the beginning of WW2 – same pretexts for invasion, same strategy.

I’m honestly lost for words… my grandfather fought Nazis (Russian side) and “lived to tell about it”. He was in Airborne and went all the way from Leningrad to Europe. He didn’t talk about the war, it seems that people who do the fighting never talk much about it afterwards.

My mom is a wise person, almost 20 years ago, when she saw Putin rising, she made correct decision, she said: “you are not staying in this country”. She prepared everything and we left. As I was growing up, I somewhat poorly followed events in Russia but each passing year, it was becoming more and more clear – Russia is going backwards in time and off the rails. Business were taken away by Putin and his gang, news become more patriotic and idiotic, freedoms taken away, journalists who asked one too many questions killed or jailed, people intimidated by “internal security forces” and/or jailed/killed and on and on.

So is it surprising to see Nazi Russia? I guess not. I guess this is how it works, this is the finale – mad king with a gang of yes men and oppressed population.

Fake TIME's cover photo of Putin with Hitler's moustache ...

Goodbye TDK SoundCube

It is funny how things workout and sometimes don’t workout in life. A few years ago, I participated in a hackathon, it was a very interesting experience amplified by the front-center seat that I have taken. The experience primarily taught me one thing: no plan survives contact with a customer ( my version of the famous ). The same idea is applicable to many situations, mainly because planning and reality tend to diverge at least at one point.

So here, I’m 8 years after purchasing my “ultimate” speaker and the speaker is no longer with me, I sold it a few days back. Why am I thinking about it? For one, I have been a bit philosophical lately – life does not stand still, everything changes, customer’s mind moves on and ultimately nothing remains the same. Another reason is sunk cost bias – I spent time and money looking for the “ultimate” speaker and it didn’t make it past 8 years with me… I feel like there should be some kind of thought consolidation, lesson learned, so here I am.

Why did I part ways? Simply because I didn’t use it. In the last 4 years, I turned on the speaker probably less than a dozen times. My life has changed, I have a child, I live in a house and music time switched from late evenings to early mornings when I sit quietly and work on things. Playing music loud is out of the question and over the last few years I stopped enjoying loud music – aging is no fun. Since priorities have changed and the speaker was collecting dust, it was an appropriate time to make a decision: to cling to the past or to let go and move forward, I chose the latter.

Leaving things behind is not an easy thing (at least for me). I get attached to certain things, I let them define me in part. However, leaving things behind is a part of life – which needs to be examined, learned and practiced. Like any exercise it has its benefits – clearing mind, space and allowing for new things/experiences to flow in.

Well, it is time to say thank you for the experience and bring joy to the new owners, bye SoundCube.

Refactoring: Improving the Design of Existing Code / Рефакторинг: улучшение дизайна существующего кода

Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Refactoring (verb): to restructure software by applying a series of refactorings without changing its observable behavior.

О книге

Ах, Мартин Фолер, каждый программист хотя бы один раз слышал его имя. По какой-то ещё не осознанной причине, я всегда ассоциирую Мартина со своеобразным духовным лидером разработчиков и архитекторов. Его выступления всегда заставляют задуматься. На этой неделе я с грустью дочитал его книгу по теме рефакторинга. С грустью? Я очень, очень медленно шел по последним 30 страницам книги, переодически останавливаясь, откладывая «на потом». Что-то внутри меня не хотело заканчивать эту книгу – хотелось чтобы приключение продолжалось. Но все хорошее когда-либо заканчивается, а значит пора подвести итог.

Заметок и мыслей собралось у меня много и поэтому начну с конца: книга хорошая – стоит времени и денег! Я лично считаю, что мне стоило прочитать эту книгу на пару лет раньше – возможно, это помогло бы мне с некоторыми неправильными представлениями о разработке и рефакторинге. У книги есть 2-е редакции, первая базирована на языке Java, а вторая на Javascript. Я прочитал вторую редакцию и, хотя мой “боевой” язык программирования Java, мне очень понравились приведённые в книге примеры и идеи на Javascript-е. Стоит отметить – я НЕ фанат Javascript-а по многим причинам, однако после Java, это как доза беспечной свободы и креатива – делай что хочешь, как хочешь, даже если тебя это впоследствии убьет. Также, по словам автора, он изменил пару советов во второй редакции, так как за прошедшее время некоторые традиции в программировании изменились, однако большинство советов остались прежними. Книга делится на две части: первые 100 страниц – история о разработке софта, почему и как рефактор является неотъемлемой частью разработки и дизайна. Вторая часть (300 страниц) – “бесконечные” техники рефакторинга из одной структуры кода в другую и наоборот, с объяснениями и хорошо разобранными примерами. В итоге, я считаю, что книга подойдет разработчикам с разными уровнями опыта, но возможно не начинающим! Как ни странно (сарказм), но автор очень сильно опирается на тесты, поэтому желательно усвоить тематику заранее, а также быть хотя бы немного знакомым с TDD, не зря со-автором книги является Кент Бэк.

+: Простое и доступное изложение
+: Детально описанные примеры
+: Набор методик с объяснениями
+: Для всех разработчиков, за исключением начинающих
+: Отличные наставления
=: Хорошая, доступная, полезная книга – стоит вкладывать деньги и время.

Название: Refactoring: Improving the Design of Existing Code
Авторы: Martin Fowler & Kent Beck

Разработка и жизненный опыт

Я не люблю мешать свой жизненней опыт с обзором книги, однако в редких моментах оно того стоит. Тут я хочу обсудить некоторые советы/заметки из книги и поделиться опытом, для того чтобы другие программисты не ступали туда, где побывали уже все – поверьте оно того не стоит.

Не рефактор

“If someone says their code was broken for a couple of days while they are refactoring, you can be pretty sure they were not refactoring.”

“Если кто-то сказал что код был сломан пару дней, потому что они делали рефакторинг, можете быть уверены, это был не рефакторинг”.

Довольно рано в моей карьере я лично повстречался с таким феноменом. Один программист уходил в “рефакторинг” не на пару дней, а на неделю или две. После этого фичи ломались, новый код невозможно было смерджить и наступал хаос. Как минимум ещё неделю программисты ходили с перьями, бубнами, барабанами на шее, зачитывая мантры, танцуя вокруг огня в попытке воскресить этого Франкенштейна. Со стороны все это выглядело жутко, так как сроки горели, софт работал плохо и менеджмент смотрел на нас как на врагов народа, мечтая о плетке и кандалах.

Вытекающие последствия: менеджмент думает что вся команда не компетентна (даже если хаос сеет один программист) и на то есть причины. Доверие к команде падает и соответственно программистов начинают слушать все меньше и меньше. Далее менеджмент начинает придумывать процесс, который в теории должен предотвратить такой хаос. Слово рефакторинг считается нецензурным и употребление его разрешается только в особых и согласованных случаях. В итоге, на первых парах все отлично, фичи добавляются, софт работает, хаос остановлен. Однако код начинает медленно деградировать, так как никто не хочет/может рефакторить. Спустя некоторое время, добавление фич начинает замедляться и разработка начинает занимать все больше и больше времени.


“The whole purpose of refactoring to me is to program faster, producing more value with less effort”. “Refactoring is always done to make the code easier to understand and cheaper to modify.”

“Для меня, вся цель рефакторинга – программировать быстрее, создавая больше ценности с меньшим усилием”.
“Рефакторинг всегда делается для того, чтобы код было легче понимать и дешевле модифицировать”.

Некоторые программисты думают, что писать много кода это хорошо. Если мы забудем про память и другие ресурсы компьютера и отдельно посмотрим на “много кода”, то в теории ничего плохого в этом нет. Проблемы начинаются в тот момент, когда код нужно изменять, допустим, для новой фичи. Первая проблема: нужно много читать, вторая проблема: много понимать, третья проблема: много менять. Все эти занятия выливаются во “много времени” и как итог “много денег”.

Теоретически, проблему можно решить на корню – писать минимальный и чистый код, однако реальность диктует свои правила. Когда первый раз решаешь проблему, то редко получается с первого раза. Вариаций на “первый раз” может быть много: новая платформа, новая библиотека, отсутствие опыта, незнание домена и так далее. Реалистичное решение проблемы – постоянный рефакторинг: начал работать над кодом; прочитал; понял; посмотри, что можно исправить (очень часто, исправить можно много чего). Добавил код, пройдись ещё раз, посмотри, если ты понимаешь что-то лучше теперь, чем изначально, исправь – сделай проще.


“To really operate in an agile way, a team has to be capable and enthusiastic refactorers – and for that, many aspects of their process have to align with making refactoring a regular part of their work.”

“Чтобы по настоящему работать в agile, команда должна состоять из способных и полных энтузиазма «рефакторов» – а для этого много аспектов рабочего процесса должно выстраиваться так, чтобы рефакторинг был частью повседневной работы.”

К большому сожалению опыта с этим у меня нет. Для меня рефакторинг это часть моего личного процесса разработки. Перед тем как я пишу код, я читаю много кода, пытаясь понять что происходит и как оно работает. Пока я это делаю, я также рефакторю код по мере возможности и ценности. Потом я добавляю новую фичу и опять читаю, смотрю, думаю и рефакторю код по мере возможности и ценности. Такой режим работы возможен потому что:
⁃Я практикую TDD
⁃Большинство команды или практикует TDD или пишет хорошие тесты (советую книгу)
⁃ Там, где тестов нет или они плохие, я делаю рефакторинг исключительно автоматизированными средствами IDE.

Теперь большинство команды смотрит очень вяло на рефакторинг и обходят его стороной по возможности. Это происходит по нескольким причинам. Первая: способности и знания самих программистов у нас довольно тусклые. Вторая: культура компании такова – если ты все делаешь быстро (даже тяп-ляп и в продакшен), то ты герой и лавры тебе, а потом хоть потоп – это кто-нибудь другой разгребет. Третья: долгое время старшие программисты и архитекторы не давали рефакторить, даже банальные и простые вещи, ссылаясь на качество наших программистов. В итоге, когда я начал мой рефактор-путь, меня много критиковали, вставляли палки в колеса и так далее. Но я выжил и по меньшей мере сейчас никто ничего мне не говорит, даже если я изменил очень много кода. Но тут важное “но” – я никогда не оставляю код в сломанном состоянии и очень редко добавляю баги по причине рефакторинга. Баги в основном прокрадываются там, где плохие тести или их нет.

Методические рекомендации

“Here’s a guideline Don Roberts gave me: The first time you do something, you just do it. The second time you do something similar, you wince at the duplication, but you do the duplicate thing anyways. The third time you do something similar, you refactor.“

“Вот методические рекомендации от Дона Робертса: Когда ты первый раз что-то делаешь, то просто сделай. Когда ты делаешь что-то похожее второй раз, поморщись и сделай дубликат кода. Когда ты делаешь похожее третий раз, то делай рефакторинг”.

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

Оптимизация цикла

Я всегда придерживался аксиомы: дубликат кода – всемирное зло, которое должно быть найдено и уничтожено. Часто, когда обрабатываешь массив данных, используешь for-loop (цикл), в котором находятся “правила” изменения данных. Если правил много, то кода в цикле получается тоже много. Читать такой код занимает время и можно было бы все упростить, если сделать несколько циклов и выполнять разные правила в разных циклах по мере необходимости. Однако такой подход значит, что по массиву надо будет проходить несколько раз – в свою очередь большая “О” будет расти, а это как мы знаем из обучения в университете – зло!

Мартин на это смотрит в точности наоборот! Приоритет должен отдаваться не количеству подобных циклов, а чистоте и легкости понимания кода. Автор считает, что лучше иметь чистый код в цикле и пусть с дубликатами, чем один цикл, но без дубликатов. Объяснений тут несколько, первое: компиляторы умные и могут оптимизировать код, второе: проблемы производительности редко приходят из обработки данных в памяти, третье: если нужно оптимизировать производительность кода, то это куда легче сделать с простым кодом, чем со сложным.

Для меня это был немного сложный разворот, однако, немного подумав о своем личном опыте, я понял что это действительно так. Частенько все вкладывается в один цикл на “благо ради”, а потом код в цикле разрастается и в определенный роковой момент, кто-то по необходимости добавляет звонок на внешний ресурс (база данных, сервис или файлик). Если система начинает тормозить и нужно оптимизировать, то это превращается в кошмарный сон, так как нужно рефакторить все и сразу.

Когда хочется написать комментарий

“When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.”

“Когда чувствуешь, что нужно написать комментарий, сперва попробуй отрефакторить код таким образом, чтобы комментарий стал излишним”

Честно говоря, я даже не помню когда последний раз писал комментарии на код. Мартин не первый человек который обсуждает эту тему, на мой взгляд тематика лучше разобрана в книге дядюшки Боба – Чистый код.

Не будьте великим программистом

Statement Kent Beck often makes about himself: “I’m not a great programmer; I’m just a good programmer with great habits.”

Кен Бек часто говорит о себе: “Я не великий программист, я просто хороший программист с отличными привычками”.

Из личного опыта мне довелось поработать с великим программистом и опыт довольно интересный. С одной стороны “писькомер” с другой “Дартаньян”. Для этого великого программиста ВСЁ было крайне просто: написать сложный код; пропустить тесты, потому-что “код тривиальный”; оптимизировать до того как надо. С одной стороны я выучил много чего, работая с ним, с другой я видел ошибки, которые он делал и он не хотел даже выслушивать доводы. Великий программист ушел, его код остался и до сих пор его дизайн поражает воображение, так как там черт ногу сломит, программисты обходят его код стороной!

Тут я хочу дать пару советов программистам. Учитесь, всегда учитесь, практикуйтесь, читайте книги, блоги и документацию! Не изобретайте колесо там где оно уже давно есть. Практикуйтесь писать чистый, понятный код – помните простота сестра таланта. Изучите разные техники, включая TDD, оно всегда поможет. Заприте свое эго под большой замок, оно никому не нужно и в итоге будет только мешать. Взращивайте отличные привычки и знания.

Что говорить менеджеру о рефакторе

“What do I tell my manager about refactoring? Of course, many managers and customer don’t have the technical awareness to know how code base health impacts productivity. In these cases I give my more controversial advice: Don’t tell!”

“Что говорить менеджеру о рефакторинге? Конечно, многие менеджеры и клиенты не имеют технических знаний о том как хороший код влияет на продуктивность. В таких случаях я даю свой спорный совет: Не говорите!”

Этот совет я слышу не первый раз и не от одного человека. Много раз, когда я ходил на семинары, эта тема всплывала и ответ был одним и тем же. Если вы находитесь в таком положении, то я поддерживаю совет – делайте что надо и не нужно никому ничего говорить. Однако помните выше описанные советы и методики – это очень важно! Так же прочитайте эту книгу, она вам очень поможет.

Теперь хочу поделиться опытом альтернативного пути развития событий. Такой путь обычно происходит в не шибко умной команде с бесхребетным тимлодом, которого больше интересуют политические игры, чем технологии. В какой-то момент, рефакторинг попадет на горизонт и будет расценен как что-то мифически-полезное, но опасное и будет принят на вооружение как оружие массового поражения. Другими словами рефакторинг включат в официальный процесс работы и будут применять только там, где нужно изменить “все”. Из личного опыта такое заканчивается по двум сценариям. Первый сценарий: пишутся рефактор-карты и кладутся в бэклог, где они долго бродят, протухают и в итоге выкидываются. Второй сценарий: выделяется неделя или две на рефакторинг какого-нибудь Титаника. И тут в зависимости от программиста: или переставляются стулья на палубе или происходит такой кап-ремонт, что в последствии принимается решение такого больше не делать, подписывая договор с менеджментом об ограничении использования оружия массового поражения.


“I’m sure you have heard many times that you cannot prove that a program has no bugs by testing. That’s true, but it does not affect the ability of testing to speed up programming.“

“Я уверен что вы слышали много раз, что нельзя доказать что в программе нет багов через тестирование. И это правда, однако это не значит что тесты не помогают вам программировать быстрее.”

“Don’t let the fear that testing can’t catch all bugs stop you writing tests that catch most bugs”

“Не позволяйте страху остановить себя от написания тестов которые поймают большинство багов, лишь потому что тесты не поймают все баги”

“A suite of test is a powerful big detector that decapitates the time it takes to find bugs”

“Набор тестов это очень мощный детектор, который позволяет сократить время поиска багов”

Я лично фанат TDD и почти всегда пишу тесты. Теперь стоит отметить, что я не фанатик и понимаю, что не всегда и не везде нужно писать тесты, однако по большинству я их всегда пишу. К такому состоянию я пришел из личного опыта написания кода и считаю что тесты действительно помогают писать код быстрее и допускать меньше ошибок. Если взять один момент из моего опыта, то тесты спасли меня когда я в аварийном режиме разрабатывал патч для прода, работал по 12 часов в день и если бы не тесты, я бы не успел закончить во время. Так же стоит отметить что на протяжении почти 2-х лет, код работал четко и без ошибок или багов. Позже код был удален, так как больше не был востребован.

Pull Request

“The common pull request model, where a reviewer looks at code without the original author, doesn’t work too well. It’s better to have the original author of the code present because the author can provide context on the code and fully appreciate the reviewers’ intentions for their changes. I’ve had my best experience with this by sitting one-on-one with the original author, going through the code and refactoring as we go. The logical conclusion of this style is ‘pair programming’: continuous code review embedded within the process of programming.”

“Обще принятая модель пул реквестов, где рецензент просматривает код без автора, не работает особо хорошо. Намного лучше сидеть с автором кода, который может предоставить контекст к изменениям и обьяснить, почему были приняты те или иные решения. Из моего опыта лучше всего сидеть вместе с автором, разбирая код и делая рефакторинг на лету. Логическое завершение такого стиля работы называется: “парное программирование”, где процесс рецензии происходит по ходу разработки.”

У меня на работе пул реквест модель является де-факто. К большому сожалению, все косяки этой модели выходят на лицо, когда невозможно понять почему именно так было сделано. Сидеть с автором редкая реальность, а парное программирование запретная практика. Менеджмент считает, что это бесполезная трата денег. Я лично считаю, что это большая ошибка, так как когда работаешь парно (а с этим опыт у меня есть), то код разрабатывается быстрее. Так же довольно легко передается опыт и ремесло. Например: если новый джун. программист работает один, то зачастую это потерянное время. Он делает много ошибок или не может сделать сам вообще ничего. В итоге после нескольких дней, ему все равно приходится работать с другим программистом. Если подсчитать, было бы быстрее и дешевле сразу так сделать. Когда два опытных программиста работают вместе, то получается быстрее, проще и чище.

Однако у парного программирования есть и свои косяки. Одна большая проблема – это личность человека. Не все могут работать в паре, может кто-то жуткий интроверт и ему очень тяжело. Так же если в команде нет способа избавиться от непригодного программиста (допустим он не хочет учиться и/или не умеет программировать, а такое тоже бывает), тогда парная работа превращается в один работает, а другой спит! У нас на работе такое явление частое, а команда ничего по этому поводу сделать не может. Менеджмент по непонятным причинам не увольняет таких чудо-работников, а дает бесконечные вторые шансы. В таких ситуациях программисты начинают отказываться работать парно и по понятным причинам, в итоге результат на лицо.


“Renaming is not just an exercise in changing names. When you can’t think of a good name for something, it’s often a sign of a deeper design malaise. Puzzling over a tricky name has often led us to significant simplifications to our code.”

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

Как говориться в программировании есть две сложные задачи: придумывать названия и кэширование. Интересно, сколько существует вариаций этой шутки? Я даже не знаю сколько раз я повторял выше описанное своим программистам. Когда я перешел в новую команду и посмотрел на их тесты, то вздрогнул. Спустя пару месяцев я ввел обязательную методику по названию тестов (если интересно, пишите я раскажу) и ещё 8 месяцев объяснял почему и как, не раз объясняя, если тест не соответсвует названию, то тест слишком сложный – разбейте на несколько отдельных тестов. Уже на данный момент все идет по маслу, битв больше нет, тесты плюс/минус в хорошем состоянии. Невероятно как маленькие изменения в названии ведут к большим изменениям в коде и работе.

Запомните это

“I was just as surprised myself when Kent Beck showed me how to do this in a hotel room in Detroit two decades ago. The key to effective refactoring is recognizing that you go faster when you take tiny steps, the code is never broken, and you can compose those small steps into substantial changes. Remember that – and the rest is silence.”

“Я был очень удивлен, когда 20 лет назад Кен Бэк показал мне как это делается в комнате гостиницы в Детройте. Ключ к эффективному рефакторингу – это осознание что ты программируешь быстрее когда делаешь маленькие изменения, код никогда не ломается и ты можешь составлять маленькие изменения в большие. Запомни это, а остальное тишина.”

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

Я советую вам попробовать этот подход на себе, главный трюк – разбить работу на маленькие шаги. Стратегий много и описывать их не буду, однако оставить с пустыми руками тоже не могу – посмотрите на “Как это решить”.

Managing Geeks

I have been in the IT industry for more than a few years now and switched a few managers (and work places). Out of all the managers this far, I only had one decent one. In general all the managers I came across seem to be fairly useless. They don’t seem to support the team and always take the most convenient position on matters – which translates to the usual see nothing, do nothing. From time to time I’ve been wondering: “what makes a management job anyways?” – because from my point of view, they don’t bring any value to the team. Perhaps in other industries or places managers are essential, but in development teams…

Today I came across a very interesting article and was somewhat surprised has been written 11 years back. After few moments my surprise turned into a few thoughts, one of which: if information on good management exists, why are there so many useless managers? Naive and rhetorical question, but I do keep asking it from time to time.

If anyone is interested in managing geeks or understanding IT mentality, please read the article and I attached PDF copy in case the article got lost.