Вступление

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

О лекторе

Для начала обо мне. Я (как вам, наверное, уже должны были сказать) работаю в компании NIX Solutions Ltd. на должности директора по обучению и развитию персонала. Кроме того я успел поработать php-разработчиком, менеджером отдела продаж, начальником отдела продаж, менеджером проектов, начальником отдела php и начальником отдела .net. Это чтобы вы понимали, что эта моя лекция про ошибки начинающих программистов, которую меня попросили вам прочитать, не просто теория очередного менеджера о том, что должны делать идеальные программисты. Всё что я расскажу — суровая правда жизни. Я сам совершал многие из этих ошибок, и я постоянно вижу, как их совершают новички у нас на фирме.

Мотивация

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

Про ошибки

Ошибок, которые совершают начинающие программисты, очень-очень много. Чтобы не перечислять их все (на что не хватит времени), я решил попытаться их сгруппировать и рассмотреть наиболее типичные группы.

Ошибки

Я решил разделить ошибки на детские, тактические и стратегические. Такое разделение больше применительно для студентов, пишущих лабы, курсовики и дипломы, чем для работников IT-контор, участвующих в реальных проектах. Но, к сожалению, и среди последних встречаются те, к кому это можно приложить. Может это потому, что работники IT-контор часто являются студентами?

Детские

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

1. Невнимание к деталям. Едва ли не основным признаком профессионала является внимание к деталям. В профессиональном приложении вы никогда не увидите ничего из ниже перечисленного:
   • Недоформатирование текстов/Недовыравнивание элементов форм. Куски лейбочек, который вылезают за панели; кнопки, которые перекрывают лейбы; тексты, которые уползают за край формы.
   • Отсутствие единообразия в интерфейсе, форматировании тектов, расположении форм. Это тот случай, когда лучше «безобразно, но единообразно». Это же, кстати, отличает айтишников от всех остальных при использовании MS Word: айтишники используют стили, и потом могут легко менять вид документа, изменяя стили, а остальные каждый элемент форматируют вручную и при необходимости изменить вид заголовка второго уровня переформатировывают все заголовки 2го уровня в доке.
   • Неучитывание возможности изменения размеров формы. Самый обычный вариант тут — просто забыть о том, что формы могут меняться, забыть установить значения минимальной и максимальной ширины и высоты. Самый некрасивый и неюзабельный — задать абсолютную привязку ко всем сторонам формы, так что контролы наедут друг на друга при её увеличении. Также часто забывают запретить “распахивать” окно, хотя запрещают “ресайз”.
   • Использование названий контролов, которые за вас придумала IDE. Button1, Form2, открытьИзображениеToolStripMenuItem_Click. Этого делать нельзя, т.к. радикально ухудшает читабельность кода, а значит увеличивает стоимость его поддержки. Вообще «неговорящие» названия контролов плохо. Говорящие по-русски — спорно, т.к. часто вы будете писать приложения для заграничных заказчиков, а это означает, что русские названия методов не пройдёт процедуру приёмки исходного кода.
   • Сортировка числовых значений по правилам строк. Это часто происходит, когда значения хранятся в виде цифр (15.45), а отображаются в строковом виде (15грн.45коп.). И сортировки выполняются средствами стандартных компонентов. Надо это учитывать и реализовывать сортировки как надо.
2. Смешение парадигм процедурного и объектно-ориентированного программирования. К сожалению, на собеседованиях я очень редко встречаю претендентов, которые бы могли внятно объяснить, чем ООП лучшее. Более того — мало кто может сказать, лучше чем что. Естественно, что не понимая, зачем ООП нужно, оно применяется неправильно.
   • Применение ООП для отмазки. Чем применять ООП «для галочки», лучше его не применять вообще, т.к. с одной стороны выглядят эти попытки жалко, а с другой запутывают ваших товарищей, которые ожидают «правильного» использования ООП, раз уж оно вообще использовано.
   • Использование «глобальных переменных». Особенно в виде «Form1.condition». Это снижает читабельность кода и является симптомом того, что вы неправильно спроектировали приложение.
   • Использование статических методов, для решения бизнес-задачи. Если у вашего класса есть только поведение (методы), но нет свойств (полей), значит, вы неправильно провели анализ предметной области (не всегда, но чаще всего).
3. Неправильные комментарии. Комментарии — это отличный помощник, если их использовать по назначению. Многие игнорируют этот факт.
   • Не писать вообще. Cowboy-style. Хорошо, что преподаватели стараются с этим бороться… и порождают следующую проблему.
   • Писать очевидные комментарии. Когда что-то делается из-под палки, это всегда делается плохо. Так и тут — особенно умиляют комментарии вида «int a; // объявляем переменную». Выглядит как издёвка (особенно, если через две строчки следует алгоритм без единого комментария с кучей циклов, ифов, break’ов и с несколькими return’ами), а издеваться над сотрудниками (и преподавателями) мало того, что нехорошо, так ещё и чревато.
   • Не описывать метод/класс. С этим старается бороться IDE. Не надо ей мешать — она знает, что делает. Автодоки сохраняют время всей команде и вам лично, когда приходит время писать документацию на проект.
4. Неследование code conventions. Стандарты кодирования позволяют вам разобраться в чужом коде (или кому-то в вашем) намного быстрее и легче. Обычно программисты подсознательно следуют какому-то одному стилю, но встречаются и такие у которых 7 пятниц на неделе. В любом случае, я советую явно выбрать подходящий стиль и стараться ему следовать. По умолчанию можно использовать стандарты кодирования pear для php, sun для java и Microsoft для семейства .net.
   • Хаотичное форматирование кода. Самый клинический случай, это когда у одного и того же человека разные куски кода отличаются по форматированию. Некоторые даже говорят, что это признак маниакально-депрессивного психоза. Ну или ему просто курсовик помогали писать соседи по общаге
   • Каждый член команды использует удобную ему конвенцию. Это менее плохо, но тоже не хорошо. Для работы в команде просто необходимо принять общий стандарт кодирования, иначе это будет не работа в команде, а просто работа над одним проектом.

Детские ошибки можно перечислять и перечислять, но я ограничился только теми ошибками, которые я встретил в ваших работах больше 3х раз.

Тактические

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

1. Не иметь правильной цели для проекта. Первой и главной целью при написании курсовых, лаб и дипломов необходимо ставить «поднять свой уровень», а не «отмазаться от преподавателя». Подумайте, ведь в большинстве случаев, когда вы придёте на собеседование, эти программы будут единственным, чем вы сможете похвастаться — может стоить сделать их хорошо?
2. И так сойдёт. Отсутствие правильно цели приводит к тому, что программы делаются «тяп-ляп», как у зайца в старом мультике (все помнят?). В двух словах — на пользу это ему не пошло. Можно выделить несколько подпунктов:
   • Размещение бизнес-логики в обработчиках событий. Это наверное самая распространённая ошибка, которую совершают абсолютно все. Можем провести эксперимент — пусть честные люди поднимут руки, если они помещали решение задачи в какой-нибудь «onClick». Я так и думал… честных людей мало Чтобы побороть эту ошибку есть теоретически простой, но сложный в реализации метод… но полезный: сначала нужно написать консольное приложение, а потом докрутить к нему GUI.
   • Тестирования приложения только на допустимых значениях. Удивительно, как много приложений падает, как только ввести в поле для ввода цифр буквы. Когда вы пишете приложение, необходимо рассчитывать не на дружеского пользователя, а на агрессивную обезьяну, которая может ввести что угодно и нажать куда угодно. Приложение должно на всё реагировать корректно.
   • Хардкод. Внесение конфигурационных параметров, строковых литералов, магических цифр в код — это плохо. Для этого давным-давно придуманы специальные средства — конфигурационные файлы, файлы ресурсов, формы настроек. По возможности необходимо избегать перекомпиляции приложения, для его настройки, т.к. в реальном мире, за перекомпиляцией следует фаза развёртывания, а это очень дорого.
   • Копи-паст. Дублирование кода увеличивает стоимость его поддержки — ведь в любом коде будут производится изменения, это данность. От этого никуда деться нельзя, а значит надо будет вместо одного изменения производить много (в зависимости от количества скопированных кусков) и ещё и синхронизировать их. За правило надо взять принцип, что если какой-то кусок кода понадобился больше двух раз, то его надо выделить в метод, класс или модуль.
   • Плохой русский/украинский/английский в сопроводительной документации. Документация — это неотъемлемая часть проекта. Если документацию неприятно читать, то это отношение распространится на весь проект в целом. Что я имею в виду? Например, откровенные глупости в части про БЖД, которые кочуют из записки в записку. (Я уже говорил, что копи-паст это плохо? на документацию это тоже распространяется). Или излишне вольное обращение с украинским языком, например «разрешение монитора», это «роздільна здатніcть», а не «дозвіл», как практически у всех вас в записках.
3. Несоответствие результата и цели. Если реализовывать что-то “тяп-ляп”, то и результат получается посредственный. Любая программа решает некую бизнес задачу — вот реализация этой бизнес-задачи и есть цель вашего проекта, а значит и результат должен быть этой же реализацией. Например, если вам дали курсовой на тему «однопользовательская игра с графическим интерфейсом», то вам надо сконцентрироваться на игре, на её динамике, на удобстве интерфейса, на функциях, характерных для игр — тогда в результате у вас будет (сюрприз!) интересная однопользовательская игра. Но в большинстве случаев студенты концентрируются на том, чтобы просто сдать курсач. В итоге получается скучная игра, которой неудобно пользоваться, обёрнутая в стандартный для windows-приложений интерфейс — стандартный проект-отмазка. Это не правильно. В первую очередь надо решить поставленную задачу — это позволит вам повысить свой уровень в программировании и анализе, и как приятный побочный эффект позволит вам получить высокую оценку за неё.
   • Недостаточная проработка теоретической части проекта. Очень часто встречаются проекты, в которых не понятна задача, которую они решают. Не секрет, что большинство студенческих проектов — это некие интерфейсы к базам данных. Например, учёт книг в библиотеке, учёт шахт на Украине, учёт студентов в деканате. Это разные цели. А результат у всех один и тот же - они, по сути, они как братья близнецы — формы редактирования, поиска и добавления новых записей. ЭТО НЕ ИНТЕРЕСНО. И это не правильно. Если вы хотите добавить интереса в ваш проект, то опишите, какие насущные задачи решает проект, какие реальные процессы он автоматизирует. Не зацикливайтесь на добавлении и редактировании записей — ведь в большинстве случаев руками никто ничего добавлять не будет, т.к. базы данных уже есть и их надо просто импортировать. Редактирование не такой частый процесс — разве что кто-то выйдет замуж и сменит фамилию (если говорить про учёт студентов). Сконцентрируйтесь на правах доступа, на вариантах поиска, на том, что реально нужно. Сходите в деканат и спросите — чего нужно его работникам. Это зачтётся.
4. Обман. Да самый обычный обман пользователей (в частном случае преподавателей).
   • Если в приложении заявлена некая функциональность, то её или надо реализовать в соответствии с требованиями или в сопровождающей документации указать на ограниченность реализации. Последний пример, который приходит на ум это «экспорт в формате MS Excel». Один из ваших товарищей реализовал это в виде генерации файла значений, разделённых пробелом, которому назначалось расширение XLS. Эксель, конечно, его открывал и автоматически распарсивал, но по сути это был обман, т.к. другие офисные системы, которые читают формат XLS, его уже не понимали. Обман производит дурное впечатление, хотя одна всего лишь фраза в документации о том, что эта функция реализована в ограниченном объёме могла бы всё исправить.
   • Не использовать/неправильно использовать ООП в курсовом по предмету “объекто-ориентированное программирование” — это тоже обман.
   • покупать лабы/курсовые/дипломы — это тоже обман. Хорошо, если вы не собираетесь становиться программистом — тогда вы обманываете только преподавателя. Но если у вас есть такие планы, то вы обманываете ещё и себя.

Стратегические

Стратегические ошибки — это ошибки стиля жизни. Они связаны с долгосрочными целями или — чаще — с их отсутствием

1. Не знать, кем и почему вы хотите стать. Это основная ошибка студентов. Они думают, что до окончания ВУЗа, этот вопрос ещё не актуален. А на самом деле потом, а может быть уже и сейчас, будет поздно. Первый вопрос, который я задаю на собеседованиях: «Почему ты решил стать программистом / тестировщиком / аналитиком?» И с грустью не слышу ничего вразумительного в ответ. Это важно прежде всего для вас — если вы НЕ понимаете, почему вы хотите стать программистом, то может быть вы вовсе и не хотите им становиться? Может вы модельер, а тут только тратите своё время? Подумайте…
2. Не пытаться улучшить свой скил в программировании. Второй вопрос на собеседовании, который я задаю всем: «Что ты делаешь, чтобы стать тем, кем ты хочешь стать?» Опять же очень не часто, мне могут ответить что-то кроме «учусь на соответствующей специальности». Этого мало.
   • Не читать книг по теме. Мне это странно, но не многие читают книги, а надо — там много полезного. Кто сходу может назвать автора какой-нибудь книги по .NET? А ещё одного? А третьего? На первый вопрос ответило 10 человек из 60, на второй 3, а на третий ни одного…
   • Не писать программ, помимо лаб, курсовых и дипломов. Это мне странно больше всего. Если вы хотите стать программистом, то почему не пишете программ? На собеседованиях некоторые на вопрос “почему программирование?” задумываются и говорят что-то вроде: “я люблю творить”. Так почему не творишь? Ну да, я понимаю, что конъюнктура рынка сейчас такая, что ай-ти-специальности популярны и многие идут туда ради приличного заработка, а не тварьбы. Но тогда возникает вопрос — почему вы не выполняете курсовые и дипломы качественно и профессионально? Ведь чем вы лучше себя покажете на собеседовании, тем лучше вам предложат стартовые условия.
   • Не следить за новостями в мире выбранной технологии. Я про новости с основных сайтов по технологиям, про блоги ведущих разработчиков, про новые книги и т.д. В ВУЗе вам просто физически не могут дать мейнстрим. Вам надо понять, что вас обучают не программировании на сишарпе, а программировать на примере сишарпа. Это значит, что вам никто не мешает использовать .NET Framework 3.5, LINQ и Entity Framework, хотя и не заставляют. Это ваш выбор — надо только не лениться его сделать.
   • Не проходить различные программы сертификации. Это момент конечно спорный, т.к. они денег стоят, но они окупаются. Кроме того, вам же всё равно надо учить .net, java или php, так почему бы не поучить по специальной литературе, по подготовке к сертификациям?
3. Не знать английского. Это вообще не обсуждается: хочешь работать в ай-ти — надо знать английский. Английский сейчас де-факто стандарт в ай-ти. Помимо того, что основная масса продуктов разрабатывается для англоязычных стран, есть ещё очень важная причина: документации к продуктам/API на неанглийском не существует. Её так мало, что ей реально можно пренебречь. А так что есть, отстаёт от английской версии на полгода минимум.

А теперь самое важное

Самое важное, что вы тут должны были увидеть — это то, что детские ошибки часто являются результатом тактических, а тактические — следствие стратегических. По большому счёту, можно всё решить одним махом — исправить стратегическую ошибку №2 Если это сделать, т.е. захотеть стать хорошим программистом, то тактические и детские ошибки… нет, не пропадут, но по крайней мере из системных перейдут в категорию случайных. А случайные ошибки легко устраняются опытом. Системные же ошибки препятствуют накоплению опыта.

Заключение

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

Примечания

1. По ходу лекции больше всех записывал завкафедрой. И много кивал.
2. На вопрос про “логику в обработчиках onClick” руку не поднял не один. Мучаюсь теперь вопросом — а может надо было спросить “кто знает, что такое обработчики событий onClick?”
3. Из авторов вспомнили только Троелсена и Сеппу, то есть вообще-то одного, т.к. Сеппа по ADO книгу написал, а не по .NET. Шилдт и Рихтер видимо из моды вышли…

COTOHA,
Сентябрь 2008

Наболело, потому может быть сумбурно и непонятно, но я буду исправлять

Проблема

Моей работой является работа с персоналом. У меня даже должность так называется — директор по обучению и развитию персонала. Должность даёт много возможностей, которые мне нравятся, но есть также и ведро ложка дёгтя: с людьми я общаюсь всё более и более опосредованно. У нас в конторе, как наверняка и везде, где больше 100 человек, наличествует некая организационная иерархия, которая несколько эээ… отгораживает. Так вот очень часто получается так, что приходит человек с заявлением об увольнении… а ты удивляешься. Это мягко говоря — чаще ты стоишь как громом поражённый и не знаешь, как реагировать. Естественно, шок проходит и ты начинаешь прояснять обстановку…

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

Чья проблема?

Возникает закономерный вопрос — чья это проблема? Первый потерпевший, кто приходит в голову — работодатель. И, естественно, так и есть: ему необходимо искать замену уходящему, объяснять это клиенту, он теряет всё, что вложил в обучение, etc. А кроме того работодатели тоже люди и бывает очень неприятно терять человека, который тебе приятен, с которым ты любил поговорить, с которым ты (да, и такое бывает) дружил. Это одна сторона.

Но есть мнение, что и для работника смена работы в общем случае далеко не сахар. Попробуем пробежаться по “активной” части работников (а заодно затестить Google Blog Search), чтобы это мнение подтвердить… За пару кликов находим следующие мнения о новой работе:

• http://mifologist.livejournal.com/11539.html — человек просто не хочет работать. не факт, что у человека такое отношение сформировалось в следствие смены работы, но и обратное не доказано.
• http://blog.sribna.com/kakovo-byit-novichkom.htm — дискомфорт от смены работы присутствует, и растёт(?) http://blog.sribna.com/myisl-o-pustom-meste.htm.
• http://korey-kaplan.livejournal.com/69180.html — казалось бы новое место — новые возможности и всё такое, но негатива пока больше.
• http://s0uthern-g1rl.livejournal.com/8361.html — шило на мыло, невыполненные обещания, etc.
• http://www.femina.com.ua/a/85.shtm — куча советов про то, как себя вести на новом месте, косвенно подтверждают, что новая работа далеко не всегда мёд.

Не буду искать ссылки на success stories — нам же подтвердить надо мнение, а не опровергать . А если серьёзно, то естественно, что на новом месте часто хорошо, но главная мысль, которую я пытаюсь донести, в том, что не менее часто на новом месте точно так же, а бывает (редко), что и хуже.

Значит, как это не парадоксально звучит, увольняющийся — тоже пострадавший (да-да, не всегда, но частенько). Вот и вторая потерпевшая сторона. И дело не в том, что новое место плохое, а в том, что старое место тебе нравится. Да — там что-то стало тебя раздражать, но основная масса параметров-то тебе подходит… Иначе что ты там вообще делал?

Если всё так просто, то почему проблемы не решают?

Возвращаемся к эпиграфу. Читаем. Ага, чтоб не было обид, поясню — под “аутистом” я понимаю не клинический диагноз, а некоторые особенности поведения такие как “избирательная стеснительность”, “угрюмость”, “мороз” и в клинических случаях “напускная гордость” (термины мои, я их ниже объясню). Так почему же проблемы не решаются? Уже догадался? Да-да. Большинство работников аутисты не озвучивают свои проблемы, а те люди, которые должны решать эти проблемы (менеджеры, тимлиды, начальники отделов), такие же аутисты, как и работники не видят проблемы, если она не озвучена. Они не виноваты, что IT притягивает такой психотип . И никто не виноват, но проблема есть.

Ну и?

Ну я и предлагаю тебе, дать своей конторе 2й шанс. А ещё лучше, сделать так, чтоб его не надо было давать — просто озвучивай свои проблемы.

Естественно, я не призываю не менять работу вообще — есть разные ситуации и всё такое. К чему я призываю, так это к тому, чтобы народ не менял шило на мыло — ведь результата от этого практически нет, а все прелести перехода будут прочувствованы в полной мере. А как я уже выше говорил, подавляющее число проблем, вызывающих переходы, решабельны в рамках вашей текущей компании. И, кстати, не надо ставить знак равенства между сменой работы и сменой рода деятельности — совершенно нормально рассмотреть так называемые career opportunities внутри конторы прежде, чем искать их где-то ещё… Тем более, если компания нравится.

Чего делать-то?

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

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

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

Угрюмость: “Почему это я должен про это говорить? Пусть они меня спрашивают!” Это позиция в основном характерна для матёрых зубров. Они знают себе цену, они решают сложные технические проблемы, они боятся сказать считают, что есть специально обученные люди (те, кто выше их по иерархии), которые должны выискивать и решать проблемы. Что интересно — переходя на управленческую позицию (а такие переходы происходят часто), сразу же забывают, что проблемы надо выискивать и искренне удивляются: “а почему они просто не сказали?“

• Контраргумент: Эти “специально обученные люди” ровно такие же как ты. Они, как и ты, ожидают от окружающих рационального поведения, то есть ждут, что человек с проблемой её озвучит — это же очевидный способ решить проблему. Другими словами, нифига они не обучены, т.к. в, моём понимании, эйчарам ещё на первом курсе их эйчарского университета (если такой есть) должны запрещать ожидать от человека рационального поведения за пределами зоны его компетенции. Вооружившись этим знанием ты должен три раза заставить себя поговорить с начальством о том, что тебя беспокоит. За эти три раза ты убедишься, что способ работает и это не случайность и не совпадение, а дальше ты его будешь использовать, как используешь любой другой паттерн, который работает.

Мороз: “Всё равно ничего не поменяется, так чё я буду говорить? Уже как будет, так и будет…” Позиция рефлексирующего интеллигента. Обычно такой тип легко идёт на контакт, в процессе которого и выясняется, что начитавшись умных книг он понял, что мир дерьмо устроен неправильно, поэтому толку решать проблемы решительно никакого нет: “Ну да, у меня сломался стул, но разве вы его поменяете? Вы вон даже на CMMI level 3 сертифицироваться не можете! Какие уж тут стулья…“

• Контраргумент: Надо отделять мух от котлет. Мир конечно не идеальный, но это не повод сидеть на поломанном стуле — ведь несмотря на то, что твоя контора не Google, в её силах многое. Надо только уметь аргументировать твои потребности. Это как раз то, что пишут в умных книжках — коммуникации наше всё. Тем более, что для тебе проблема не “поговорить”, а заставить самого себя поверить в то, что это даст результат. Но! В данном случае можно даже не верить, но всё равно поговорить — пусть шансы получить желаемое, по твоему мнению, малы, но если не поговорить, то они начинают вообще стремиться к нулю. Простая логика. Так что — говори, хуже не будет.

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

• Контраргумент: В сад. Если взаимоотношения с работодателем для тебя унижение, то тебе или ещё раз в детский сад на переобучение или ты работаешь на фашистов. Но дело в том, что фашистов-то у нас на рынке и нет, так что… в сад.

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

“Я знаю, что мою проблему решить кроме как через конфликт нельзя. А скандалить я не хочу…” Позиция немного неуверенных в себе особ. Или действительно неконфликтных, или тех, кто боится, что о них пойдёт слава склочника, что скажется на будущей карьере. По большому счёту, это сочетание “мороза” и “стеснительности”. Между прочим, такие люди оказывают медвежью услугу тем, кто остаётся работать там, откуда они ушли — ведь причина конфликта осталась неразрешённой.

• Контраргумент 1: Во-первых, ты не знаешь, неизбежен ли скандал. Возможно, если немного подумать, то конфликт можно разрешить и без скандала — для этого есть много техник, и они много где описаны.
• Контраргумент 2: Во-вторых, лучше скандал, разрешающий конфликт, чем неразрешённый конфликт. Я так понимаю, что такой аргумент чаще всего возникает при конфликте с непосредственным начальником. И я понимаю, что, раз ты уходишь, тебе конечно уже всё равно, но ведь твои товарищи остаются работать вокруг этой бомбы замедленного действия. Так сделай им подарок на прощание… Для этого надо воспользоваться одним из альтернативных каналов связи на фирме — ведь в любой фирме, кроме твоего непосредственного начальника, есть ещё как минимум пара людей, которые тебя готовы выслушать. Чаще всего это служба HR. Просто пойди к ним, или к кому-угодно, кому ты доверяешь, и изложи ситуацию. Ситуации бывают разные, но в общем случае со своим начальником ты работать скорее всего больше не будешь, однако твоя искренность сыграет свою роль и тебе предложат те самые career opportunities. У тебя будет выбор, которого не было бы, если бы ты молча написал заявление об уходе.
• Контраргумент 3: В-третьих, “слухи о склочности” это миф. Я про такие никогда не слышал, несмотря на то, что IT-бизнес в Украине — это большая деревня (вру, слышал но исключительно про склочников-директоров компаний, а не про инженеров или менеджерский состав). А кроме того, поверь — конторы достаточно компетентны, чтобы разобраться с ситуацией и не делать поспешных выводов.

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

А это лечится?

Спешу обрадовать — лечится! Чтобы с такой позиции соскочить, надо просто понять простую вещь — вы и компания это не родитель и ребёнок (ну кроме случаев, когда вы действительно ведёте себя как ребёнок), а партнёры. Другими словами надо повзрослеть (не в плане возраста, а в терминах трансакционного анализа). Взрослый понимает, что так как продолжать партнёрские отношения — выгодно обоим сторонам, то и прилагать усилия к их продолжению должны обе стороны. У такого подхода есть ещё один дополнительный бонус — ты сможешь активнее влиять на свою карьеру. Молча это бы не получилось.

А гарантия есть?

Гарантии, что проблему решат, нет. С одной стороны. Очевидно, что не всё получается, как планируется, но это не повод отказываться от планирования. Точно так же и в нашей ситуации — озвучивание не гарантирует решение проблему, но здорово повышает шансы на это.

А с другой стороны, есть гарантия, что ты будешь уверен в ответе. Если ты молчишь, а твои потребности не удовлетворяются, то ты находишься в состоянии недостатка информации: то ли про твои потребности не знают, то ли их просто не собираются удовлетворять. Когда же ты озвучил потребности, то ты тут же получил результат: или удовлетворение потребности, или план по её удовлетворению, или же причины отказа в удовлетворении. А с открытыми глазами гораздо удобнее куда-то идти.

Смысл в том, что если, ты попробовал решить проблему, а тебе сказали “извини, не можем”, то на новой работе ты не будешь мучиться мыслью “а что если?” — ты будешь совершенно точно знать, что нет.

Резюме и отказ от ответственности

Озвучивание своих потребностей и проблем, конечно, не панацея. Но лекарство очень действенное. Итак основные тезисы:

• Чтобы решить проблему, её надо озвучить.
• Причины, по которым проблемы не озвучивают, чаще всего иррациональны.
• Чтобы устранить причину, необходимо её проанализировать. Просто проанализировать и этого в большинстве случаев хватит, чтобы она перестала быть причиной.
• В общем: озвучивание проблем не гарантирует, но очень сильно повышает шансы на их решение.
• В частности: этот подход не гарантирует продолжение работы на старом месте, но он гарантирует отсутствие сомнений в правильности решения, если ты уволился.
• Однако, если ввести решение проблем (вместо их замалчивания) в привычку, то и мыслей о другой работы может не появляться очень долго — ведь всё устраивает на старой, а что может быть лучше!?!

Бонус: немножко кейсов для управленца

1. Если человек очень долго не просит образец заявления на отпуск, то, скорее всего, он скоро попросит образец заявления об увольнении.
2. Если человек громко восхищается в твоём присутствии наличием холодильника в соседнем отделе, то это он на самом деле не просто восхищается, а намекает. Ферштейн?
3. И вообще, если сотрудник чем-то громко возмущается (или — реже — восхищается), то на это действительно надо обратить внимание. Ты же помнишь — они по разным причинам не хотят говорить о проблемах\потребностях, но раз заговорили (пусть даже косвенно), то это важно.
4. Не надо ждать, пока сотрудник захочет развиваться в другой конторе. Развивай его сам! Сотрудники очень ценят инициативу начальства, поэтому не сиди сложа руки.
5. Иногда у сотрудника возникают такие потребности, которые компания удовлетворить не в состоянии (читай — компании это не выгодно). В таких случаях про это надо рассказать совершенно честно и сразу. Ведь ты бы хотел, чтоб по отношению к тебе поступили так же? Искренность ценится высоко.

Оригінал українською.

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

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

Цель этой статьи хоть немного побороть дикость, а именно чуток просветить народ про особенности слобожанского свадебного рушника. Естественно в интересной для программиста форме.

Сам обряд я не буду критиковать, хотя и есть за что, я хочу объяснить каким должен быть “правильный” рушник как это понималось на Слобожанщине.
Я, и многие другие, уже становились на неправильный (вот не верю, что хоть у кого-то был правильный) рушник, но вот некоторым это только предстоит. Так вот я собственно и хочу им помочь сделать правильно, если это им вообще надо. А если не надо, то этот пост можно рассматривать просто как экстравагантную задачу.

Итак, слабо без гугла вскрыть код наших прабабушек?

Дерево рода

Если приглядеться к оригиналу, то на первом этаже мы видим маленькое неприметное чёрное нечто. Оказывается это нечто — дерево рода. По нему можно многое рассказать о роде (семье) брачующегося. Оно растёт из горшка — в данном случае из чего-то, что напоминает избушку на курьих ножках. Само дерево в закодированном виде содержит информацию про 2 колена рода брачующегося.

На рисунке слева показано 2 дерева рода — одно могло бы быть на моём свадебном рушнике (если бы он был правильным), а другое дерево могло бы быть на рушнике моей мамы (если бы у неё вообще был рушник).

Теперь читаю “код”:

1. На момент свадьбы, у моей мамы были мама и папа, бабушка и дедушка по маминой линии. Её отец (мой дед) — детдомовский, поэтому по папиной линии нет ни деда ни бабушки. Кроме того по маминой линии наличествовали три дяди и тётя, причём один дядя был младше её матери, а двое других и тётя — старше. Как я уже говорил, мой дед из детдома, поэтому тёть и дядь с его стороны не было. Ну и до кучи у мамы было 2 брата — старший и младший, а также старшая сестра.
2. На момент моей свадьбы у меня были мама и папа, бабушка по маминой линии и дедушка по папиной (к сожалению папина мама и мамин папа не дожили до этого светлого дня). Так случилось, что мамины братья тоже умерли, так что у меня по маминой линии осталась только одна тётя — мамина старшая сестра. От папы тоже есть родич — дядя, папин младший брат. Ну и, конечно, не могу не упомянуть своего младшего брата.

Собственно задача

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

Ответы принимаются в формате письма с картинкой на мой мейл. Письмо должно включать картинка (ваше дерево рода) и текст (описание рода), чтобы я мог оценить, правильно ли оно построено.

Комментарии тут без премодерации, поэтому просто по-человечески прошу — не надо постить спойлер. Вам это чести не сделает, а другим удовольствие поломаете. Ну и ещё раз — решать без Google.com!

Очень хочется из правильных ответов построить сад деревьев рода айтишников.

Отказ от ответственности

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

А эту версию я случайно нашёл в инете. Тем не менее она выглядит достаточно правдоподобной.

С другой стороны если у кого есть возможность (живы бабушки или прабабушки) уточнить, то я был бы очень благодарен за уточнения или подтверждения.