Monthly Archives: December 2010

Почему не любят PHP или мода в ИТ и разработке Software

Оговорки

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

Что такое PHP?

С помощью PHP можно быстро создать web-приложение. Начать писать можно очень быстро.

Есть некоторые проблемы с производительностью, но они по разному решаются. Например с помощью MVC. HipHop от Facebook. Собственно Facebook по большей частью написан на PHP и поэтому если им удалось решить проблему с производительностью, то и другим удастся.

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

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

А все ли хорошо с PHP?

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

Если же взять например .NET или Java со всеми ее технологиями, то там порог входа на много выше и если человек может писать на одном из этих языков, то, как правило, он уже что-то умеет и понимает.
 Т.е. с одной стороны это усложнение, а с другой – это фильтр.

Это что-то мне напоминает ситуацию с тем, почему многие предпочитают пить кофе в приличных кафе, а не в первой встречной забегаловке, хотя кофе может быть таким же, но цена в несколько раз отличаться. Мы платим за приятный интерьер, отсутствие любителей звать оффицианта через весь зал, глупых фраз вроде “А что ж вы сразу не сказали, что кофе пьете без сахара” и т.д. Мы платим за все, кроме кофе.

Да, конечно есть языки со своей узкой областью применимостью, но эта статья не об этом.

Что же все таки происходит?

А здесь банальный отрыв от реальности. Как правило программисты хотят сделать что-то “классное”. Они заинтересоване в классном проекте. Но их особо не интересует, продан ли продукт 1000 пользователей или миллиону. Да и собственно это и понятно – от этих цифр для них ничего не меняется.

И вот здесь весь подвох кроется в слове “классное”. Ну скучно программистам сидеть и просто достигать бизнес-цели заказчиков. Поэтому они и ищут что-то “интересное”, “новенькое”. И там уже столько всего наворочено, что никокой нормальный человек со стороны уже ничего не поймет – ну и правильно сделает, себе дороже.
 Это уже сродни моде.

И инетрессные задачи действительно важно для программистов. Известно, что многие предпочитают известные компании, например Google или Facebook, не смотря на то, что при работе в банковской сфере вознаграждения значительно выше.

Хочу так же описать один пример дикости в ПО.
Возникло куча библиотек для логирования в Java. Нет, чтобы они повоевали и выжила сильнейшая. Так нет, написали библиотеку SLF4J которая как бы их всех сразу разрешает использовать….. и поддерживать, и обновлять, и изучать.

Так и этого мало, теперь вышел новый язык, о чудо, Scala – очередная серебряная, пуля.  И уже Java-исты поглядывают в ту сторону.

Это мне напоминает дебри шаблонов в C++. Задачи решаются все лучше и лучше, пока не доходит до того, что невозможно найти людей, которые могут потом этими решениями пользоваться или что-то там поменять.

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

Не спроста появились Getting Real у 37 сигналов.

Дополнительная сложность ко всему этому в том, что внутренне качество продукта не сразу видно снаружи и толковым технарям сложно это объяснить менеджерам. А это может привести к очень плохим последствиям. Т.е. на первый взгляд будет казаться что два разработчика делают одно и тоже, но через несколько лет один продукт невозможно развивать дальше, хотя со вторым таких проблем не возникает. И здесь оценивать только по краткосрочному результату опасно.

Говорят, что фундамент ПО легко менять – да это правда. Фумент то как раз легко поменять А вот если менять архитектуру, то это больше уже на кое-что другое похоже….. Я бы сказал на смену электропроводки в отделении “Скорой помощи”. Причем в ней уже за много лет добавляли свои розетки с нарушением всех норм. Но это было допустимо, потому что так нужно было, чтобы подключить аппарат искусственного дыхания для больного, попавшего в катастрофу. И если все привести в порядок, то медсестра, которая вас не предупредила, что обязательно нужна розетка, в следующий раз в критический момент просто не найдет розетку и это будет иметь очень печальные последствия, потому что кто-то просто сделал так, как посчитал нужным.
Это к тому, что в одних случаях эта проводка меняется по ходу дела, а во вторых доводится до критического состояния. А заметным это становится уже тогда, когда лампочки перестают гореть.

Резюме

  1. Речь о том, что главное упущено.
  2. Этой модой движут два мотива. Первый — подражание с целью перенять опыт или хороший вкус, второй — страх оказаться вне общества, быть осмеянным (боязнь изоляции). 
  3. Остается неясным, как искать компромис между долгосрочной и краткосрочной производительность.
  4. При необходимости нужно уметь быстро разбираться в новых технологиях для которых очевидно, что они будут успешными. И ни в коем случае не ловиться на все “новенькое”.

Скрытые возможности

Можно думать, что с этим делать. Но я поставил вопрос по другому: какие это открывает  возможности?

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

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

3. Если Software Development – это Core компании, то видимо нужно создавать такую атмосферу, чтобы в компании было “модно”, пристижно работать, начиная с выбора технологий, заканчивая самим продуктом. Как это делать, точно знаю. Но кто-то очевидно это моду делает: Oracle, Microsoft? Зачем? Дороже вход – больше денег? Тут могу лишь процитировать диалог из фильма о моде “Дьявол носит Prada“:

– Я еще только учусь разбираться во всех этих шмотках…
– “В этих шмотках”?
Вы думаете, что они к вам не имеют отношения.
Вы подходите к шкафу и выбираете, не знаю, этот мешковатый голубой свитер поскольку хотите всем показать, что вы – человек серьезный  и вас совсем не волнует, во что вы одеты, но вы не знаете о том, что этот свитер не просто голубой.
Не лазурный. Не бирюзовый, а небесно-голубой. И вам невдомек, что в 2002 году Де Ля Рента создал коллекцию платьев такого цвета, а затем, Ив Сен-Лоран – коллекцию небесно-голубых френчей.
К нему нужен жакет.
И вскоре другие дизайнеры ввели небесно-голубой цвет в палитру.
А затем он просочился в крупные магазины одежды, а потом спускаясь все ниже, достиг магазина уцененных товаров где вы его и выудили.
Для появления этого оттенка были затрачены миллионы и тяжкий труд.
И хотя вы уверены, что сделанный вами выбор подчеркивает вашу независимость от моды, на самом деле вы носите свитер, который был выбран для вас людьми в этой самой комнате… из горы “шмоток”.

Управляющие ЛЮДЬМИ в IT компаниях о распределенных командах и зарплатах

Посетил Встречу управляющих ЛЮДЬМИ в IT компаниях.

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

От Александра Дымо и обсуждений аудитории

  • Начинать день с совещания (по сути, start up meeting), чтобы разогреть команду, и люди не читали первых пол-дня Хабрахабр и не пили кофе, а сразу начали работать. Все остальное – второстепенное.
  • В стартапах часто нельзя набрать задач даже на неделю – используется burn-down с недотягивающим до нуля низом, который должен во время спринта вырасти (“речка”).
  • Нужно всегда иметь возможность узнать, что человек делает в любой момент времени. В удаленных командах нельзя посмотреть из-за плеча.
  • Демократия не работает. В любом случае не явно получает власть тот, кто сильнее, как правило, технически.
  • Нужно всегда искать компромис между повышением авторитета (говорить всегда правильные вещи) и развитием (ошибаться)
  • Работает правило “Мы подумали и я решил” и псевдо-возможность выбора.
  • Коммуникацию нужно не только увеличивать, но и уменьшать.
  • В удаленных командах высокое качество кода более критично, чем в локализированных, поскольку нельзя заглянуть через плечо.
  • В проекте с 10 людьми есть опыт, что новый человек создает 160% проблем на 1 коммит.
  • Если у кандидата есть дети – не брать на удаленную работу.
  • Фрилансеры работаею на результат, а в продукте надо чтобы команда любила продукт.
  • Если после запугивания на интервью человек остался – точно выживет.
  • На интервью давать нерешаемые задачи – можно узнать много нового.
  • 1 “персик” на 50 “лимонов” (будет еще ниже)
  • Мотивация – это работать в продуктовой команде (От себя: ну и чего ж тогда программисты продажников не долюбливают, в продукте ж их больше чем в аутсорсе)
  • При найме неудачного человека падает производительность у всех: (а) из за “быдлокода” (б) “он мало делает, зачем мне напрягаться?”
  • Для удаленной работы идеально брать тех кто работал в Open Source продуктах.
  • Есть люди, у которой нет той части мозга, которая парсит чужой код.
  • “Красоту” кода можна проверить на задании на 5 строк кода.

От Василия Кривоноса и обсуждений аудитории

  • Иногда менеджеры хотят разрушить личность человека путем иницирования войны между чувством справедливости и естественным принципом найменьшего сопротивления (“получить больше наименьшими усилиями”) – дают возможность человеку повышать зарплату самому себе.
  • На интервью узнают только навыки и умения, а также опыт – как человек работает в реальной ситуации узнать трудно.
  • При наличии знаний производительность зависит от мотивации.
  • ЗП на много выше, если есть гарячая позиции – простой съедает гораздо больше денег.
  • Уникальным востребованным сотрудникам платят много, за риски остаться без работы.
  • Переговоры о повышении ЗП, если пришел уникальный сотрудник, с точки зрения сравнения с другими не понятно как вести. Сотрудник не может объяснить свои требования, а менеджер свои – не с чем сравнивать. Менеджеру лучше приводить к чему то среднерыночному по ближайшей похожей вакансии, сотруднику – выбирать лучшее среди компаний.
  • Есть компании, которые ищут “персиков” и готовы платить больше в несколько раз, чем “лимонам”. Компании не могут распознать “персиков” на собеседовании. “Персикам” нужно искать правильные компании и получить вначале как “лимоны” и быстро расти.
  • “Персик” от “лимонов” удирает.
  • Если есть команда синьеров и никого нового не хочет больше принимать, только таких крутых как они, наймите девушку. Плевать на опыт.
  • По статистике при смене работы ЗП повышается в среднем на 25%. За меньшее не перейдут, а больше не дадут. Это от 25 до 35. Больше – нифига не повышать, они либо всего боятся, либо им нифига не надо, либо они CEO и им не кому повышать (они находятся в вечной войне справедливости и принципом найменьшего сопротивления).
  • При частой смене компаний ЗП растет выше, чем при росте в одной компании.
  • Ценится “быть в индустрии”. Правило: один язык в год.
  • IT-шники верят в какую-то справедливость. Если миф разрушен – их домкратом не поднимешь.
  • Бонус должен быть не менее 50% от ЗП, за что-то очень супер конкретное, например за фик супермегабаги, должен платиться вовремя.
  • Безпроцентрый кредит сотруднику еквивалентен повышению зарплаты, особенно чувствуется, как только сотрудник его выплатит.
  • Хочешь узнать, сильно ли выросла ЗП – пропей дельту и оцени бодун.
  • Повыгать нужно гигиенически и с ростом профессионализма – человек должен знать за что.
  • Если твоя ЗП в нижней части вилки, иди выбивай, на тебе экономят. Наглость – второе счастье.
  • Зарплаты друг друга не знают, пока не побухают.
  • Повыжают ЗП на 0-X-2X-3Х. Для этого всех сортируют на 4 группы и делят деньги которые выбили из “Биг Босса”. Х обычно около 6%.
  • Уходят, как правило лучшие, потому что им не доплачивают.
  • Компания теряет 18 зарплат ИТ-шника, который уходит. Один HR, который предотвратил уход одного технаря в год, с лихвой отбивает свою ЗП. Дешевле платить немного выше, чем ждать, когда человек прийдет за повышением ЗП сам.
  • Повышение ЗП человеку, который пришел ее выбивать, работает максимум один раз.
  • В IT очень мало менеджеров, обычно это координаторы проектов.
  • Западные заказчики не понимают, почему у нас такой быстрый рост левелов у программистов.
  • Если нет денег на повышение ЗП, то и не нужно тратить деньги на дорогой чай и другие офисные понты. Сотрудники не подсчитывает эти копейки, а ищут, как уличить руководство в “аморальности”.
  • Схема повышения ЗП должна быть прозрачной.
  • У “торгашей” спрашивать причины повышения.
  • На “скромнягах” не экономить – уйдут как только узнают, что на них экономят и потеряете 18 ЗП. Дайте чуть меньше рыночного, а остаток вкладывайте в развитие сотрудника.
  • Если бухгалтер случайно накинула 100 баксов мотивированному сотруднику и он превратился в динамомашину, то сотруднику ничего не говорить и не менять, бухгалтера наказать.
  • Если сотрудник хочет больше денег, предложить подработать в фрилансе. Устанет искать первый заказ и успокоется.
  • Если человек хорошо ведет переговоры, то есть основания полагать что плохо кодирует.

А также:

  • Рекрутеры на слово Java реагируют как бык на красное покрывало, “Java наше все”.
  • Чудо-миф о том, что деньги айтишникам не нужны – туфта. Зарплата должна рости с профессионализмом.
  • В Киеве еще есть компании, которым нужнй чистые C++-ки (без MFC, Win32 и прочего хвоста) 
  • После того, как людям становится тесно в больших компаниях, они часто уходят в стартапы. В основном это сильные инженеры.
  • Люди делятся информацией и не жалеют ее.  У всех все очень интересно.
  • 495 маршрутка от  Республиканского Стадиона в Циклум не ездит 🙂
  • В Циклуме  такая-же кофе машина, как и в нескольких других компаниях, в которых я был – кофе тоже вкусный. Офис – обычный для больших компаний, на хорошем уровне. Да простят меня сотрудники компании за такую транслитерацию, ну не помню я как правильно произносится.
  • Было около 30-и человек.

Вика, еще раз спасибо за организацию и еще раз с прошедшим ДР!!!

A few tips for a successful Google interview

Ниже рекомментации от Гугла, как готовиться к техническому интервью с ними.
Больше всего меня рассмешила фраза “A few tips”. Это ж для кого они Few? – очень повеселило 🙂

Но зато есть еще “A few last tips” 🙂

И еще Гугл одна из немногих компаний, которая нанимает и готова платить за Algorithmic and Math Skills.

Небольшое видео о процессе найма:

Итак, выглядят рекомендации следующим образом:

A few tips for a successful Google interview:

The interview will include topics such as coding, data structures, algorithms, computer science theory, and systems design. We recommend you spend some time exploring our website to get into the right mind frame. Google Publications and Labs is a good starting point.

Google Labs Links:
http://labs.google.com
http://labs.google.com/papers.html

System Design Publications:
Google File System (http://labs.google.com/papers/gfs.html)
Google Bigtable (http://labs.google.com/papers/bigtable.html)
Google MapReduce (http://labs.google.com/papers/mapreduce.html)

Books to assist you in preparing for your interview:
“Programming Interviews Exposed: Secrets to Landing Your Next Job”
Authors: John Mongan, Noah Suojanen, and Eric Giguиre (Wiley Computer Publishing)

“Programming Pearls”
Author: Jon Bentley

“Introduction to Algorithms”
Authors: Cormen, Leiserson, Rivest & Stein

Please review the following topics:
Big-O notations also known as “the run time characteristic of an algorithm”. You may want to refresh hash tables, heaps, binary trees, linked lists, depth-first search, recursion. For more information on Algorithms you can visit:
http://www.topcoder.com/tc?module=Static&d1=tutorials&d2=alg_index

Coding: You should know at least one programming language really well, and it should preferably be C++ or Java. C# is OK too, since it’s pretty similar to Java. You will be expected to write some code in at least some of your interviews. You will be expected to know a fair amount of detail about your favorite programming language.

Sorting: Know how to sort. Don’t do bubble-sort. You should know the details of at least one n*log(n) sorting algorithm, preferably two (say, quick sort and merge sort). Merge sort can be highly useful in situations where quick sort is impractical, so take a look at it.

Hashtables: Arguably the single most important data structure known to mankind. You absolutely should know how they work. Be able to implement one using only arrays in your favorite language, in about the space of one interview.

Trees: Know about trees; basic tree construction, traversal and manipulation algorithms. Familiarize yourself with binary trees, n-ary trees, and trie-trees. Be familiar with at least one type of balanced binary tree, whether it’s a red/black tree, a splay tree or an AVL tree, and know how it’s implemented. Understand tree traversal

Algorithms: BFS and DFS, and know the difference between inorder, postorder and preorder.

Graphs: Graphs are really important at Google. There are 3 basic ways to represent a graph in memory (objects and pointers, matrix, and adjacency list); familiarize yourself with each representation and its pros & cons. You should know the basic graph traversal algorithms: breadth-first search and depth-first search. Know their computational complexity, their tradeoffs, and how to implement them in real code. If you get a chance, try to study up on fancier algorithms, such as Dijkstra and A*.

Other Data Structures: You should study up on as many other data structures and algorithms as possible. You should especially know about the most famous classes of NP-complete problems, such as traveling salesman and the knapsack problem, and be able to recognize them when an interviewer asks you them in disguise. Find out whatNP-complete means.

Mathematics: Some interviewers ask basic discrete math questions. This is more prevalent at Google than at other companies because counting problems, probability problems, and other Discrete Math 101 situations surrounds us. Spend some time before the interview refreshing your memory on (or teaching yourself) the essentials of combinatorics and probability. You should be familiar with n-choose-k problems and their ilk – the more the better.

Operating Systems: Know about processes, threads and concurrency issues. Know about locks and mutexes and semaphores and monitors and how they work. Knowabout deadlock and livelock and how to avoid them. Know what resources a processes needs, and a thread needs, and how context switching works, and how it’s initiated by the operating system and underlying hardware. Know a little about scheduling. The world is rapidly moving towards multi-core, so know the fundamentals of “modern” concurrency constructs. For information on System

Design:
http://research.google.com/pubs/DistributedSystemsandParallelComputing.html

Helpful links:
– http://www.google.com/support/jobs/bin/static.py?page=gettingintogoogle.html
– http://www.youtube.com/watch?v=w887NIa_V9w
– http://www.youtube.com/lifeatgoogle
– http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html

A few last tips:
• Talk through your thought process about the questions you are asked. In all of Google’s interviews, our engineers are evaluating not only your technical abilities but also how you approach problems and how you try to solve them.
• Ask clarifying questions if you do not understand the problem or need more information. Many of the questions asked in Google interviews are deliberately underspecified because our engineers are looking to see how you engage the problem. In particular, they are looking to see which areas leap to your mind as the most important piece of the technological puzzle you’ve been presented.
• Think about ways to improve the solution you’ll present. In many cases, the first answer that springs to mind isn’t the most elegant solution and may need some refining. It’s definitely worthwhile to talk about your initial thoughts to a question, but jumping immediately into presenting a brute force solution will be received less well than taking time to compose a more efficient solution.