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 dice.com – 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?
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.
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 (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 лет назад Кен Бэк показал мне как это делается в комнате гостиницы в Детройте. Ключ к эффективному рефакторингу – это осознание что ты программируешь быстрее когда делаешь маленькие изменения, код никогда не ломается и ты можешь составлять маленькие изменения в большие. Запомни это, а остальное тишина.”
Думаю, весь цимис успеха заключается именно в маленьких шагах. Зачастую мы думаем что это муторно, излишне и медленно. Однако если цель и задача в том чтобы сделать что-то хорошо и четко, то самый быстрый способ это делать работу маленькими фокусированными шагами. Возможно такой подход идет в разрез с общепринятой идеологией, но для меня он работает и работает хорошо.
Я советую вам попробовать этот подход на себе, главный трюк – разбить работу на маленькие шаги. Стратегий много и описывать их не буду, однако оставить с пустыми руками тоже не могу – посмотрите на “Как это решить”.
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.
Пока я учился в университете я встретил одного интересного и забавного человека. Витя выделялся ни только своим забавным и непредсказуемым ходом мыслей, но так же и необычайным стремлением познать и/или сделать эксперимент. Местами я воспринимал его как назойливого человека и пару раз хотелось ему дать в нос. На то время мне было тяжело понять его ход мыслей, и то что тогда казалось “назойливостью” и местами “ехидством”, на данный момент осознается простым и чистым стремлением понять/изучить!
Университет это именно то место и время когда именно этим и нужно заниматься. Нужно смотреть на вещи и людей с разных точек зрения, стремится рассмотреть и изучить все с разных сторон. Стоит нажать на слабые места и посмотреть что будет, так же стоит переоценить жизненные ценности и выучить приоритеты в жизни.
Мне бы очень хотелось сказать что на данный момент я понимаю Витю и то как он мыслил и что он делал, но я этого сказать не могу. Понимание другого человека является практически невыполнимой миссией. Все что я понял наблюдая за Витей так это то что у каждого человека есть бриллиантовый аспект – что-то что хочется украсть у его, просто подойти, вырвать из его тела и вставить себе. Витя умел уходить в себя и просто концентрироваться на работе как ни кто другой. В один момент он сидит на кресле и над чем-то работает, а в другой он весело ходит по дому и рассказывает о разных идеях/вещах. И вот момент проходит и он сного сидит в кресле и работает. Меня это местами пугало, так как когда он работал, то в его глазах можно было видеть неимоверное количество концентрации. Ему было все равно на все что происходило вокруг. Были моменты когда орала музыка, гремели стены, студенты пили и орали, а он просто сидел в кресле и работал. Мне даже казалось, что если студенческий дом превратиться в военную зону, где будут стрелять, бросать гранаты, ездить танки, то Витя все равно будет сидеть спокойно в кресле и работать – даже не обращая внимания что рядом приземлилась граната.
Я считаю что это один из самых замечательных аспектов которым человек может владеть. Именно это я и выучил от Вити. Как я уже говорил, человека практически нельзя целиком понять, можно только понять какой-то аспект. Аспекты могут быть разные, как позитивные так и негативные – это зависит от смотрящего. Я как наблюдающий могу выявить определенные аспекты в человеке и/или в его работе, а дальше сделать свои выводы. Мой вывод был и есть очень простой, поняв/изучив особо выделяющейся аспект другого человека (просто наблюдая за ним и/или изучая его работы) либо принять это на “вооружение” либо отбросить.
Я думаю что это очень важный фактор в саморазвитии, так как мы (как люди) всегда окружены людьми, работами/продуктами других и просто природным миром. Поэтому очень важно пытаться найти во всем этом мимо проходящем именно позитивные или просто полезные аспекты. Стоит брать хорошее и пропускать мимо плохое.
Думаю на этой ноте я и остановлю мысль.
Учитесь, изучайте и не когда не сдавайтесь.
Выходные пролетели, я ничего на них не делал… и даже скажу больше, такое ощущение что я заболеваю… так как все выходные фактически провел в кровати. Не знаю то чего, но все время хотелось спать и голова была тяжелая. Сейчас сижу и пью напиток… пол чашки лемона (выжитого) с медом, а другая с горячей водой. Не знаю если это поможет, но нужно все же принимать витамин Си.
Вообщем что-то меня “сгубило” на этой неделе… кто-то оно все криво шло. Я хотел посидеть поработать, но увы… очень досадно и обидно. Я не навижу такие выходные, не люблю что бы время просто пролетало мимио. Конечно иногда приятно выбраться и все такое, но в последнее время мне что-то хочется все больше и больше работать, не знаю почему.
Местами думаю что работа это все то что создает вообще весь смысл в жизни. Мы рождаемся, вокруг все работают, мы учимся и потом тоже занимаем свое место в мире как рабочие этой системы. Пока я учился в университете я все думал что в жизни делать и куда податься… типо должен быть высший смысл и как говорят “что-то большее к жизни”, но в последнее время я прихожу к выводу что ничего нету, просто работа и ежедневная рутина. Конечно можно все бросить, собрать рюкзак и отправиться в путешествие, так некоторые люди делают. Но я особо путешествовать с рюкзаком на спине не хочу, единственное что приходит в голову так это делать что-то полезное для общества. Одни становятся докторами, инженерами, другие работают на стройках, но мы все что-то делаем на благо общества… мы все часть системы и походу не куда от этого не деться. Выбор всегда в том какой частью системы ты станешь.
Ладно не буду вдаваться в философию… пойду все же лягу, а то я как-то себя хреного чувствую.
Что-то в последнее время я вспоминаю много чего из прошлого и вот вспомнил один разговор который произошел лет так 8 назад. В то время я активно общался с одним человеком и у нас произошел интересный момент.
Обсуждали спутниц жизни (девушек) и как-то свернули на тему, а чем твоя половина должна интересовать, тем же что и ты или абсолютно другим? И тут мы разошлись во мнение. Я говорил что интересы должны быть одинаковыми, а он говорил что разными. Спор особо долго не продолжался, но аргументы были просты: если есть общие интересы то будет проще общаться, а так же принимать участие в общих мероприятиях. С другой стороны если разные интересы то можно будет развить кругозор, так как ты будешь вводить девушку в свой круг интересов, а она тебя в её.
Я точно не помню чем все закончилось, но спустя 8 лет я думаю что вариант с общими интересами все же лучше. Если есть два человека и у них нету ничего общего, то тяжело сосуществовать. Начиная от недопонимания и заканчиваю аргументами на тему “как надо жить”. Я думаю что общения между двумя людьми должно происходить хотя бы на каком-то уровне взаимопонимания. А такой уровень не возможен если нету хотя бы как общей точки соприкосновения. Другими словами если изначально тебе нравиться бокс, а ей баллет и в обратном порядке тебе не нравиться баллет, а ей бокс, то и в дальнейшем не будет понимаю на эту тему. Далее эмпирическим путем можно догадаться что если два человека имеют разное мировоззрение и не пытаются понять друг друга, то у них не будет точки соприкосновения и как итог взаимопонимания.
Так же можно поднять вопрос о том стоил ли такие отношения продолжать ( если уже существует )? Тут же в голову залетела мысль о войне миров – чем в теории можно описать выше описанную ситуацию. Если уже дано, что два человека не понимают и не хотят друг друга понимать, но при этом сосуществуют. В теории такое сосуществование ни к чему хорошему не должно привести. Так как любое решение о том что делать дальше и как строить жизнь ( или дом или задний двор или какую машину купить и так далее ) будет встречено двумя разными точками зрения и как последствие может произойти соперничество и перейти в открытый конфликт.
Теперь следуя мысли о соперничестве. Капитализм и открытый рынок всегда (в теории) рад соперничеству – так как это приводит к низким ценам и высокому качеству продуктом – это опять же в теории ( я не буду объяснять почему в теории, кому интересно пишите ). Но интересно если такой же принцип работает в отношениях, семье или другой социальной группе? Думаю что стоит обсудить это дело по пунктам:
1) В семье такого рода отношения могут не работать. Я предполагаю что соперничество в семье приведет к сферам влияния и политике. Например сын за папу, а дочь за маму или на оборот. И даже если нету детей то такого рода соперничество выльется к постоянным спорам и дебатам – “что же лучше делать”. Это приведет за собой стресс и как последствие разные заболеваниям – как итог меньшей работоспособности и худшему уровню жизни. Далее это может привести к само-разрушению семьи и индивидуума, не говоря о моральных и психологических последствиях.
2) Что же происходит в социальной группе? Например вы живете в комуне и ей выделили площадь на обустройство – например для футбольной площадки или что-то в этом роде. Если существует эта комуна/соц. группа имеет две подгруппы людей с геометрически разными взглядами то получиться конфликт – например одна говорит стоить нужно школу, а другая спорт зал. В теории есть несколько сценариев что произойдет дальше но по сути или площадку отберет гос-во и построит там что считает нужным или будет компромисс аля ни рыба ни мясо или кто-то сдастся (что не предполагают изначальные данные) и будет что-то одно. Но что более интересно, так это шанс того что будет много стресса, конфликт и как последствие испорченные отношения внутри группы/комуны.
Если я прав, то тогда в отношениях как и в соц. группе нужно иметь что-то общее и не просто что-то, а то что создает общий интерес на конкретную тему. Например любовь к музыке – это сближает двух людей и позволяет найти общий язык/понимание. Или например в соц. группе может быть общий интерес деньги и авто – тогда группа может решить сделать свою авто-компанию и когда интересы сходятся то люди понимают друг-друга хотя бы на двух плоскостях (деньги и машины). Если есть взаимопонимание то будет компромисс и будет завтра, но для этого нужно вкладывать силы и работу так как взаимопонимание редко когда просто дано!
Ладно, на этом я остановлюсь. Всем чирз и любите друг друга.
P.S: Без знаний нет пониманий и без пониманий нету знаний.
И вот я сижу и пишу в первый раз за довольно долгое время. Конечно пишу я чуть чаще, но не о личном… Мне кажется что раньше когда был в университете, я писал о личном как-то больше – мысли, философия и все такое. А сейчас все времени нету, я разрываюсь между всем и сразу: работа, дом, сон, работа… – вообщем мысль понятна. И вот меня уже пара дней мучает что-то внутри. Не пишу я ни о чем таком “высоком”.
А на дворе уже конец Июля… кажется что я только начал работать, а нет… уже месяцев 5 прошло. И вот во дворе темно, а в голове только одно: сейчас пойду спать, проснусь а уже не 2011 год, а где-то так 2022 – 10 лет спустя. Я все работаю и работаю, а жизнь пролетает так не заметно мимо! Это неизбежность и так понятно, страшно становиться только при мысли что я делаю все тоже самое: думаю о лучшем времени, о начальстве о том как бы купить какую нить вещицу и так далее… Перефразирую выше написание одним словом – рутина! И не просто рутина, а именно это жизненное… как бы выразиться дерьмо. Тут не то что бы я сильно был против, но меня напрягает именно факт того что жизнь по сути идет в каком-то закрытом цикле – родился, вырос, выучился, поработал, выростил детей ( или нет ) и умер. В промежутках только жрешь, срешь и думаешь о инвестициях, покупках и как бы устроиться помягче. А что в итоге? Приходит старость, ты не кому не нужен, а посмотришь назад и что?
Ну вот купил я 20 новых машин, 10 новых домов, 100 кухонных комбайнов, 50 новых компьютеров и что? Что все это дает? Теплое чувство что мол когда это было в моде, у меня это было! Какой я крутой из себя… о да! Как-то это все не значительно. Меня как-то тошнит от этой мысли… не хочется после себя оставить свалку отходов, кредитную историю и немного денег… Хочется что-то подарить человечеству, кто-то полезное, что-то что бы можно было использовать на благое в будущем. Конечно можно удариться в философию и сказать – а это все говно, мол вот Энштейн оставил после себя ядерную бомбу, где тут светлое ( в переносном смысле )? Понятно что все можно использовать как для хорошего так и для плохого. Можно взять в руку карандаш и написать стихи или песню или что-то ещё, а можно взять и воткнуть его кому нить в глотку или разжечь огонь и спалить все здание… Но факт что карандаш есть и он полезен как о одном так и в другом случае!
Конечно я не могу сделать карандаш, я даже с химией особо не знаком… но можно ведь что-то после себя оставить, что-то что пригодиться. Например Лайнус Торвальдс сделал и он останется в истории не только как создатель куска софта, а как человек положивший начало чего-то нового и уж точно останется в истории открытого ПО (софта). Я явно не Торвальдс, но мне хочется что-то оставить после себя…
Но вот стрелки на часах уже подходят к 0:00, а это значит пора спать, потом работать и опять понеслось… считаем дни на календаре. Ладно надеюсь что с тяжелой работой прийдет и какое-то удовлетворение жизнью.
Давно ничего не писал о своих мыслях и вроде хочется, а вроде и не как немогу написать… Сегодня моя мама прислал мне интересное письмо и я решил что стоит его запостить на своем сайте, так как понравилось:
Билл Гейтс назвал 11 правил для подростков. Он считает, что ежедневное обучение оптимизму и политкорректности формирует поколение далекое от реальности, а это неизбежно приводит к неудачам во взрослом мире.
Правило 1: Жизнь несправедлива привыкните к этому!
Правило 2: Миру наплевать на вашу самооценку. Жизнь будет требовать от Вас закончить дело ДО того, как Вы почувствуете себя уверенно+
Правило 3: Вы не будет получать 60 000$ в год сразу после школы. Вы не станете вице-президентом компании со спутниковым телефоном в машине, прежде чем Вы заработаете на них.
Правило 4: Вы считаете, что учитель слишком требователен? Подождите, когда станете начальником Вы.
Правило 5: Подавать гамбургеры не ниже вашего достоинства. Ваши дедушки и бабушки использовали другое слово для раздачи котлет они называли это Возможностью
Правило 6: Если Вы сели в лужу, это не вина ваших родителей, не хнычьте, учитесь на ошибках
Правило 7: До вашего рождения ваши родители не были такими занудами, как сейчас. Они стали ими, оплачивая ваши счета, стирая вашу одежду, и выслушивая ваши рассуждения о себе любимом. Поэтому прежде, чем начнете
спасать мир от поколения своих родителей, вычистите сортир в собственной комнате
Правило 8: Ваша школа, может быть, и покончила с делением на лидеров и неудачников, но жизнь НЕТ. В некоторых школах не ставят плохих оценок и дают вам столько попыток, сколько вам требуется для правильного ответа. Это не имеет НИЧЕГО общего с реальной жизнью.
Правило 9: Жизнь не поделена на семестры. У вас не будет летних каникул и найдется немного работодателей, которые заинтересованы в том, чтобы вы НАШЛИ СЕБЯ. Ищите за свой счет!
Правило 10: Телевидение это НЕ реальная жизнь. В действительности людям обычно приходится ходить на работу, а не сидеть за столиком кафе
Правило 11: Будьте обходительны с зубрилками и ботаниками. Не исключено, что вскоре вы будете работать на одного из них
Думаю что комментировать не буду, а просто оставлю все как есть.
Чирз и завтра будет лучше!
