Новый исполнительный директор Сатья Наделла продолжает реформы в Microsoft. На этот раз пришло время кардинального сокращения штата.

Несколько часов назад (в главном офисе Microsoft было ранее утро) CEO компании разослал сотрудникам письмо, в котором рассказал о грядущих реформах. Увольнение 18 000 человек — самое крупное сокращение штата в 39-летней истории Microsoft.

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

Для сравнения мы взяли список профессий, названия которых работодатели наиболее часто вводят при поиске резюме в сфере информационных технологий. Проанализировано 87,5 тыс. резюме, размещенных или обновленных в первом полугодии.

Важно, от редакции: то, что люди говорят или не говорят о себе в резюме — не всегда значит, что они такие или не такие на самом деле.

О своей ответственности тестировщики и бизнес-аналитики говорят в резюме вдвое чаще, чем программисты java и C++. Возможно, они считают, что в их профессии эти качества приоритетнее?



А как обстоят дела с коммуникабельностью?

Чем одна компания отличается от другой? Почему заказчики с удовольствием заказывают у одной компании, но совершенно не замечают другую? Почему одна компания разрабатывает софт полтора года, а другая управляется всего за полгода? Есть множество причин, но всех их объединяет одна особенность – успешные компании эффективны. О том, как повысить эффективность компании на базе её отдельных составляющих, поговорим в этой статье.

Изображение: Austin Distel — Unsplash

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

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

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

Так получилось, что тесть и теща у меня доктора педагогических наук. Что приводит к тому, что волей-неволей начинаешь постигать различные полезные методики :)

Однажды, после какого-то ученого совета за виски чаем на кухне тесть говорит: Саш, а вот как ты считаешь, почему люди чего-то не делают?

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

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

• Почему менеджеров проектов надо пересаживать в отдельное здание
• Что делать, когда ваш заказчик не пользуется вашей системой отчетов
• Как раскачать low-performer’а

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

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

Перевод статьи выполнен компанией-локализатором Alconost.

Мы с партнером считаем себя первопроходцами в области развития коворкинга в регионах. Наш коворкинг появился в Самаре почти полтора года назад. За это время мы уже успели набить множество шишек, порадоваться каким-то успехам, попробовать разные пути развития: в общем, опыта набрались достаточно. Именно им я бы и хотел поделиться.



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

До сих пор не можете спать, пытаясь осмыслить понятия ковариантности и контравариантности? Чувствуете, как они дышат вам в спину, но когда оборачиваетесь ничего не находите? Есть решение!

Меня зовут Никита, и сегодня мы попытаемся заставить механизм в голове работать корректно. Вас ожидает максимально доступное рассмотрение темы вариантности в примерах. Добро пожаловать под кат.

Лично меня жизнь убедила, что люди это капитал. Особенно в нашей отрасли все зависит от людей. Если кто-то сомневается в этом, то очень рекомендую книгу шведов Кьелла А. Нордстрема, Йонаса Риддерстрале, «Бизнес в стиле фанк. Капитал пляшет под дудку таланта». Книга не новая, но, имхо, очень доходчиво разъясняет, почему Маркс, Ленин и Мао Дзэдун были правы в современном мире это именно так.

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

С началом эпохи HTML5, рынку понадобилось большое количество JavaScript программистов. Многие специалисты по другим языкам, начали массово переориентироваться на JavaScript. Я много раз видел, как программисты с большим опытом ругали этот, один из самых гибких и могучих, язык, не понимая его принципов. В этой статье я постараюсь рассказать суть и философию JavaScript. Здесь будет всего 4 строчки кода и много-много того, что не напишут в учебниках. Обещаю, что вы полюбите этот язык, или по крайней мере, станете эффективнее в нём. Итак, поехали!

Вводная часть

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

Прочитав обе статьи, вы сможете составить адекватное собственное мнение на заданную тему.

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

Введение

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

С удовольствием приму критику и выслушаю мнения «другой стороны».

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

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

На моем прошлом месте работы я перестал использовать наш продукт, потому что Linux перестал быть приоритетом. Называлась куча причин — малая доля пользователей, «только для гиков», «все журналисты используют маки» и прочее.

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

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

Более того, разработчиков, работающих на Linux более 15 лет начали заставлять использовать другие платформы для разработки. Не стоит и говорить о том, что они не могут их использовать столь же комфортно и продуктивно.

Многое еще можно сказать, но все это — история о предательстве. Компания предала не только лояльных пользователей их продукта, но и своих собственных разработчиков. Результат? Потеря мотивации и массовые увольнения. В том числе и мое.

Друзья! Мы все очень любим (или не любим) поговорить о шаблонах проектирования. Лично я их сильно недолюбливаю, т.к. большинство из них достаточно очевидны для более или менее опытного разработчика, а шаблонность мышления еще никому в жизни не помогала.

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

В повседневной жизни я стараюсь не употреблять слово «программист». Оно для меня несет негативный оттенок и сразу вспоминаются 90-е, когда кого только программистами не называли. Они и картриджи у принтеров меняли и бабушкам-бухгалтерам помогали их первый комп осваивать. Помните это нетленное «Ты же программист!»? В общем дискредитировало себя это слово.

Я как-то привык своих людей называть разработчиками (developers) и для меня программист — это эдакий антипод разработчика. Ну и с годами опыта я познал большое количество антипаттернов для хорошего разработчика, пользоваться которыми он должен как можно реже. Чем реже я их слышу, тем я счастливее. Итак, приступаем.

001. А у меня на компе работает

Эта фраза знакома всем, кто хотя бы несколько месяцев работает в индустрии и просто должна быть исключена из лексикона любого разработчика. Чувак, если ты отправляешь на тестирование код, который не работает у тебя на компе, то тебе не место в профессии! По определению у тебя на компе код всегда работает. Разве может быть иначе? А не работает он у тестировщика, клиента, да кого угодно, потому, что ты не учел какие-то нюансы, различия в окружении, данных, погоде на Марсе и твоя задача выяснить, что именно и исправить, а не пытаться сразу откосить и доказать свою невиновность. Нет ничего страшного в том, что ты чего-то не учел. В моей практике бывали случаи учесть которые мог бы только… Да никто не мог бы!

В странах бывшего СССР сложилось вполне определённое отношение к тестировщику как к роли второго плана:

• На роль тестировщика готовы брать кого угодно, кто умеет достаточно уверенно нажимать на кнопочки
• Тестировщики редко участвуют в судьбе проекта, принимают решения по требованиям и срокам
• Тестировщиков стараются подключать как можно позже, когда надо «покликать» и «поикать ошибки»
• За исключением небольшого числа продуктовых компаний, большинство работодателей предлагают тестировщикам зарплату в 1,5-2 раза ниже, чем разработчикам.

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

Начну с истории о программистах, которую мне приходилось слышать неоднократно.

Я попросил Джо написать простенькую программу, которая делает <xyz>. Работы там было на несколько часов, в худшем случае на день. Ему понадобилось несколько дней, за который он написал гораздо более сложный фреймворк, чем требовалось. Почему он снова так намудрил?

Возможно, дело в том, что Джо – Абстрактно ориентированный программист (АОП).

Когда-то давным-давно каждый отвечал за свою работу и ни у кого не было вопросов. Люди трудились на предприятиях: в конторах и на заводах. Были, правда, исключения — люди искусства, аристократы, предприниматели — но их было немного.

Законы, постановления и статистика — все строилось на этом предположении; но чем дальше, тем больше то, чем люди занимались расходилось с тем, что понималось под этой анахроничной рубрикой из 50-х. У меня есть опыт объяснения представителям пограничной службы того, что моя «работа» состоит в заключении контрактов в стране А для клиента в стране B, а также в написании книг и продаже приложений. Повторять не советую.

В какое прекрасное время мы живём! Вот пишешь ты программу и понадобилась тебе библиотека для чего-нибудь — она точно найдется! Многие библиотеки лежат в opensource и даже распространяются по приятным лицензиям типа LGPL, взял — и решил проблему. Делов-то: способ подключения описан в readme, библиотека предоставляет красивые интерфейсы, демка есть (она даже компилируется и работает). Вообще ООП со всеми его идеями абстракций, интерфейсов, инкапсуляции внутренних данных — мощнейшая штука (тут без иронии).

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


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