Cord

>юлозит вульвой
крутое выражение, надо запомнить

У нас тест является обязательным при наборе, идет вдобавку к резюме.

Беглый взгляд на тест (5 задачи, пхп, базы, ксс+js, архитектурная) позволяет отсеять 90% людей, которые не подходят.

Зачем тратить свое время на собеседование, у вас других задач мало?

Дайте 3-5 задач типа тычки-галочки + две такие свободные, где надо порассуждать, и не принимайте на собеседование без них.

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

в одном комменте видел

а может, просто за общий посыл статьи.

Надо радоваться.
Ура, я женщина! (С)

его, похоже, за мат забанили.

добавил строку в начало поста.
если три коммента еще будет — уберу в черновики.

Я вот тоже думаю.
Убрать в черновики может?

>Масло маслянное? В ошибках программирования, наверное тоже, виноват только программист.
Ну модно (и я был таким раньше, и иногда бываю сейчас) обвинять кого угодно, только не себя. Не те программисты — вот посыл статьи.

>Автор предыдущей статьи был абсолютно прав в том, что для каждой работы есть некий стереотип человека, который будет эту самую работу лучше всего выполнять. Грубо говоря, человеку с лидерскими и безнес-скилами работать на «конвеере сайтов» будет ни разу не интересно. Ошибкой автора было перенести свой стереотип на остальные проекты (дескать всем нужны только забитые ботаники.)

Ну и я высказал свое мнение на этот счет, насчет идеального. Цитирую: «Идеальный программист не пишет плохой код, не срывает сроков и не существует.»

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

Согласен

офигеть, его самого забанили? странно.
жалко вообще.

он же вроде не матерился, просто написал свой взгляд

Он достаточно крутой человек вообще, посмотрел пару постов. Поднял бизнес, как понимаю, с нуля, создал рабочие места. Молодец :)

Просто в эмоциях написал статью, с которой я не совсем согласен. Никто же не запрещает обмен мнениями?

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

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

Знаете в чем прикол?

Напишите эту логику на стороне БД, и работать иногда будет раз в 10-100 быстрее. :)
Иногда скорость важнее красоты

Initializing Motivation Protocol…

ну если мы обработку, какие баннеры, перенесем на клиента, будет ппц)

ну там уже до нас было кеширование в виде файлов. изначально структура была слишком крутая и универсальная, и все варианты показа баннеров обсчитывались в ПХП ООП :) мы упростили структуру еще к тому же, провели рефакторинг.

Могу сказать про недавний опыт.

Мы переписывали движок баннерокрутилки, полученный от коллег. Наш хороший разработчик переписал все на ООП PHP. Мы пытались что-то оптимизировать, но оно даже под абешкой не взлетало (50 запросов в секунду должно плевать с одного сервака, получали 99% fails).
В конце-концов в результате оптимизаций на профайлинге стала очевидность важности правильной архитектуры. Ниже этапы оптимизации и вывод.
1. Сначала убрали лишнее ООП. Помогло, не сильно
2. Увидели, что крутые ООП-оболочки над БД сильно тормозят. Переписали на голом PDO
3. Но и голое PDO стало тормозить. 90% времени съедает, 400 мс.
4. По моему предложению перенесли логику в БД. Так как там была операция в цикле и ряд запросов.
5. Сначала хранимки в БД написали " в лоб" — циклы и тд. Помогло, не сильно — 50% не работало под нагрузкой.
6. С участием нашего DBA, выдающего специалиста, переделали циклы в хранимке на язык реляционной БД — в один запрос, убрали временные таблицы из логики, и так далее.
7. В итоге менее 10% фейлов, и система стала жить на нагрузке.

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

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

Для того, чтобы люди ассоциировали какие-то НЕХ с реальностью, часто нужно их наделять эмоциональными поступками, и нередко — антропологичностью.

Почитайте у Каганова на эту тему. Супер-повесть про кротовые норы отсасывает, а повесть про живую машину вдруг становится популярной. Хотя в первой ДОСТОВЕРНОСТИ может быть миллион. А способности ВЫЗЫВАТЬ ЭМОЦИИ у зрителя/читателя — минимум.

Поэтому парень все сделал верно.

Крайне интересно.

Будущее не просто рядом, а уже наступает.

Такой стиль вашего коммента бесит. Это вы издеваетесь?

Значит, давайте по-порядку.

Во-первых, я в той статьей дополнил каждый пункт личным примером. Вы плохо смотрите.

Во-вторых, аяксовое сохранение по CTRL+Enter мне было не сразу понятно. Оно скидывает в черновики, хотя логичнее было бы публиковать (именно эта кнопка основная).

В-третьих, где запрещение этого правилами?

В-четвертых, я стараюсь писать содержательные статьи, и о разном. Сам не люблю воду.

(дубль)

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

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

Ну мы делаем IT в туризме. К примеру, наш проект это Tophotels.ru
Много крутых проектов, лидируем на рынке.

я занимаюсь внутренней автоматизацией, расти еще очень много

я не сразу осилил пересохранение

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

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

в общем, там было непросто :)

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

данная есть изложение моего опыта

+100

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

но некоторые взлетели. самое простое и незатейливое взлетело :)

Согласен, что не только для управленца. Для профессионалов во многих сферах подходят.

я то же самое написал

мысли схожи))

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

IMHO разумеется.

Кого-то тошит от плюсов и он боготворит Джаву, или си шарп.

А так, любой язык под свои задачи. Офисную автоматизацию я писал на Дельфях, клиент-серверное приложение для управление роботом Кавасаки на с++, под веб — в зависимости от задач, ASP/.NET, потом был перл, питон, пхп.
Все это можно и на Джаве, и на сях написать с определенными усилиями, но зачем?

и Java, и .NET обладает рядом существенных недостатков (и технических, и организационных, связанных с разработкой на этих платформах и разработчиками).

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

впрочем, в современном мире железом можно заткнуть даже тормозную и глюкавую платформу. и это дело вкуса, как говорится.

Single point of truth = SPOT = DRY

KISS = keep it simple, stupid

эвристические правила, работают много где

Супер!
Молодец, уважаю таких, кто создает.

если не секрет, когда вы за отметку топа вышли ($120k/year)?

да, я читал
очень крутой Уэлч.

habrahabr.ru/post/113463/

>например, если проектировщик такой умный в юмл-диаграммах, то почему надо кому-то повторять работу? Пусть генерирует код из них. Или сам и пишет

+1000

Я у себя выбросил ежедневные митинги, совещания и тд.
только при необходимости.

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

если бы все еще это юзали, но это другой вопрос:)

искусство войны?

>Недавно показательная вещь случилась. Говорю: полдня надо еще, чтобы полностью покрыть тестами. Человек, который уж очень хочет забрать код, говорит: «не надо, мы тебе и так доверяем». В итоге нашли баг, который был как раз в том месте, не покрытом тестами. Но они потратили 2 дня на его поиски. (не ТДД, каюсь, но то был проект — взять готовый код, оптимизировать и рефакторить).

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

коммуникации рулят.

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

золотые слова!