* От переводчика. Хочу обратить внимание всех анонимных хейтеров, которые, увы, все еще есть на хабре, что эта статья — перевод. А посему я не являюсь автором и не несу ответственность за идеи и мысли, написанные здесь. И еще я не работаю в Microsoft.
Замечания и предложения пишите, пожалуйста, в личку. Спасибо за понимание.

Какая самая плохая вещь в работе в Microsoft?

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

Первая вещь — количество людей вне Microsoft, которые сомневаются в компании

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

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

Стоп! Microsoft делает стулья? Нет, не напрямую. Но как насчет части этого стула? Собранный на заводе, которые управляются ПО от… угадали, Microsoft. Перевезенный на грузовиках, сделанных с помощью программ Microsoft, по дорогам, построенным с помощью Microsoft. Если вы не предпочитаете быть сбитым автобусом, то подумайте о той роли, которую Microsoft играет, чтобы сделать вашего ребенка здоровым.

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

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

Моя трёхлетняя дочка София в последнее время частенько упоминает «ноль», например, в таком контексте:

— Соня, вот ты вроде сначала не послушалась, а затем послушалась, что же получается?..
— Ну… ноль!

Т.е. ощущение отрицательных чисел и нейтральности нуля уже имеет, о как. Скоро поинтересуется: почему же это на ноль делить нельзя?
И вот решил я простыми словами записать всё, что я ещё помню про деление на ноль и всё такое.

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

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

Когда мы создаем статические макеты интерфейсов (будь то сайтов или мобильных приложений) в Photoshop, мы не слишком сильно задумываемся над тем, как этот макет поведет себя в динамике. Стив Джобс как то сказал: «Дизайн это не то как продукт выглядит, это то как он работает». Наше впечатление от продукта формируется на основании многих факторов, но самым важным является комфортное взаимодействие с ним.

Анимация прокрутки

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

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

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

Продолжаем нашу серию статей по мотивам опросов: на этот раз мы решили измерить расхождение между тем, как представляют рабочий день программиста студенты-технари, и тем, как все происходит на самом деле. Студенты МГТУ им. Баумана, которые учатся в Технопарке, снова согласились ответить на наши вопросы.

Для этого мы провели небольшое исследование, в ходе которого ожидаемо выяснилось, что не все представления о «сферическом рабочем дне в вакууме» совпадают с реальностью. Студенты готовы программировать по 790 часов в год при условии, что половину рабочего времени будут проводить в социальных сетях.

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

Вопрос программистам: Представьте себе свой типичный рабочий день. Какой процент времени в среднем занимает каждая из перечисленных активностей?

• Обдумываю задачу, ищу пути решения
• Изучаю информацию, читаю маны
• Пишу код
• Тестирую, ищу баги
• Участвую во встречах, планерках, брейнштормах, провожу собеседования
• Читаю Хабрахабр, Роем и другое полезное в интернете
• Читаю / пишу письма, ставлю / читаю таски в трекере
• Сижу в социальных сетях
• Общаюсь с коллегами по не рабочим вопросам
• Ем, пью, сплю

Далее для сравнения мы собрали ответы студентов Технопарка.

Сегодня на глаза попался старый вопрос "Почему работодатель предпочитает нанимать веб-разработчика в офис?": habrahabr.ru/qa/22292. Вопрос был задан еще в 2012 году, но, на мой взгляд, ситуация с тех пор не сильно изменилась.

Коллеги, тут есть серьезное недопонимание, которое давно пора устранить.

Многие, как мне кажется, представляют себе фрилансера примерно так:

• Приходит на какую-то отдельную небольшую задачу, выполняет ее и уходит.
• Работает над несколькими мелкими проектами одновременно. Либо имеет постоянную работу, а фрилансером просто подрабатывает в оставшееся время.
• Его не беспокоит проект в целом. Только то, за что он отвечает.
• Огораживает себя техническими заданиями. И из-за каждой новой плюшки может возникнуть конфликт.
• Работает когда хочет. С ним сложно связаться.

Техническое собеседование – практически неотъемлемый атрибут трудоустройства любого разработчика, а для старших разработчиков – проведение их (собеседований) ещё и чуть ли не повседневная обязанность. Но как за короткий срок (в идеале 20-30 минут) составить у себя более менее приемлемое представление о реальном опыте соискателя?

Некоторое время назад, я решил, что хочу знать больше подробностей о работе многопоточности в .NET и что я уделял этому незаслуженно мало внимания в прошлом. Информации на эту тему великое множество (отправной точкой я для себя выбрал этот раздел книги «C# in a nutshell»), но, как оказалось, только малая часть ресурсов пытаются объяснить что-то в деталях.

Каждый мастер должен знать свои инструменты, а что может использоваться чаще коллекций? Поэтому я решил сделать небольшой обзор многопоточных коллекций и начать с ConcurrentDictionary (беглый обзор уже встречался здесь, но его там совсем мало). Вообще, я несколько удивился, что такой статьи для .NET еще нет (зато хватает по Java).

Итак, поехали.

Если не знаешь, надо не бояться, а узнавать.
Айн Рэнд “Атлант расправил плечи”



Добрый день, меня зовут Игорь Томич и я лектор курсов iOS-разработки и сооснователь онлайн курсов Master Up. Это мой первый пост в наш корпоративный блог, в котором я решил поделиться советами для начинающих iOS-разработчиков. Свое первое приложение для iOS я начал писать в начале 2009 года, а в мае 2012 году провел первый курс обучения по рарзработке под эту же платформу и к этому времени у меня скопилось достаточно “часто повторяемых ошибок” и путей их решения.

Привет, Хабр!

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

Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

Игра в планирование

Наш мир слишком изменчив и непредсказуем, чтобы полагаться на постоянство ситуации. То же происходит и при разработке программного обеспечения: о редкой системе можно сказать, что ее окончательный вид был заранее известен в деталях еще в самом начале разработки. Обычно у заказчика аппетит приходит во время еды: ему постоянно хочется что-то поменять, что-то улучшить, а что-то вообще выбросить из системы. Это и есть изменчивость требований, которую все так боятся. К счастью, человеку дано умение прогнозировать возможные варианты и, таким образом, держать ситуацию под контролем.
В экстремальном программировании планирование — неотъемлемая часть разработки и то, что планы могут поменяться, учитывается с самого начала. Той точкой опоры, методикой, которая позволяет прогнозировать ситуацию и безболезненно мириться с изменениями, является игра в планирование. В ходе такой игры можно быстро собрать известные требования к системе, оценить и запланировать их разработку в соответствии с приоритетностью.
Как и любая другая игра, планирование имеет своих участников и свою цель. Ключевой фигурой является, конечно же, заказчик. Именно он сообщает о необходимости той или иной функциональности. Программисты же дают ориентировочную оценку каждой функциональности. Прелесть игры в планирование заключается в единстве цели и солидарности разработчика и заказчика: в случае победы побеждают все, в случае поражения все проигрывают. Но при этом каждый участник идет к победе своей дорогой: заказчик выбирает наиболее важные задачи в соответствии с бюджетом, а программист оценивает задачи в соответствии со своими возможностями по их реализации.
Экстремальное программирование предполагает, что разработчики в состоянии сами решить, за какой промежуток времени они справятся со своими задачами и кто из них охотнее бы решил одну задачу, а кто другую.
В идеальной ситуации игра в планирование с привлечением заказчика и программиста должна проводиться каждые 3-6 недель, до начала следующей итерации разработки. Это позволяет довольно просто внести коррективы в соответствии с успехами и неудачами предыдущей итерации.

Более 10 лет занимаясь ядрёной смесью из математики, программирования и управления проектами – всем тем, что входит в современное понимание Информационных Технологий — я сформулировал простые правила, которые считаю подходящими для любого профессионала, связанного с ИТ.

С нами связался хабражитель Александр, блогер и предприниматель из Екатеринбурга, который в ноябре переезжает в Долину и хотел задать свои вопросы. Получилось вот такое интервью-ответ на вопросы о Кремниевой Долине, предпринимательстве, русскоговорящем бизнес-сообществе AmBAR, предпринимательстве в России и российских ассоциациях. На вопросы отвечал тот, кто сам не так давно переехал в Кремниевую Долину и имеет т.н. «свежий взгляд».

Вообще, всем, кто хочет получить некоторый ликбез о Кремниевой Долине, советуем почитать вот эту очень вдохновенную статью основателя Evernote (компании, стоимостью в 2 млрд. долларов) Степана Пачикова, которую опубликовали в «Огоньке» в 1995 году. А у вас есть какие-то вопросы о Кремниевой Долине? Не стесняйтесь задавать в комментариях.

Итак, поехали.

Все мы наслышаны о красивом коде. Книги и страницы специализированных ресурсов пестрят рекомендациями, стандартами и просто хорошими советами. Современные языки предлагают множество путей изящного выражения идей разработчика. Вообще все хорошо. Вроде бы. Но реальная жизнь сурова. По ряду вполне объективных причин только самые счастливые из нас имеют возможность работать с действительно качественной кодовой базой. Большинство же, зная чуть ли не все подробности идеального способа работы, живут здесь и сейчас, за пределами рая, довольствуясь имеющимся.

Но как сделать свою жизнь лучше? Как заставить уровень качества кода расти. Приведу несколько собственных правил-размышлений на эту тему.