alaudo

alaudo

Пикабушник
Дата рождения: 26 марта 1979
поставил 152 плюса и 59 минусов
отредактировал 0 постов
проголосовал за 0 редактирований
Награды:
С Днем рождения, Пикабу!5 лет на Пикабуболее 1000 подписчиков
18К рейтинг 4306 подписчиков 19 подписок 34 поста 12 в горячем

Чем занимаются разные программисты

Более интересные вещи вынес пост-ответ здесь: Ответ Аноним в «Секреты вашей профессии, о которых лучше не говорить»

Вот более прозаические вещи.

0. Есть разные дисциплины с разными порогами входа. Для каких-то дисциплин (веб-разработка) достаточно просто браузера. Где-то же нужно понимать в электроннике или иметь дорогое оборудование. Заплата не всегда напрямую от этого зависит: если вы специалист очень узкого профиля и для Вашей работы нужно сложное оборудование, то заплата будет конечно неплохая, но потребность в таких спецах может быть ниже, чем в более "ходовых" дисциплинах.

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

2. По мере роста всё меньше нужны технические навыки и всё больше организационные и личностные, в частности:

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

2.1. Как суметь аргументировать свою точку зрения (как объяснить идею на пальцах в 4-5 предложениях или в крайнем случае используя Paint/Whiteboard и мышку).

2.2. Как правильно оценить сложность проекта, суметь отказаться от сложного решения или вообще от какой-то части проекта, если есть большой риск провала.

3. Что делает (индивидуальный) разработчик (IC -- individual contributor):

3.0. Пишет код (ну куда ж без него)

3.0.0 Сам код в каком-то виде

3.0.1 Пишет тесты (либо начиная с них, либо заканчивая ими)

3.0.2 Пишет прототип, если проект очень большой или долгий, для демо.

3.0.3 Рефакторит код перед открытием pull request.

3.0.4 Учитывает замечания коллег с pull request перед тем как добавить изменения в репозиторий.

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

3.2. Представляет свою работу в разным митингах внутри команды и вне её.

3.2.0 Со временем количество твоих проектов накапливается и вот уже каждый день по митингу по разным проектам :)

3.3. Занимается самообразованием (читает книги, делает курсы, просто занимается чем-то интересным, чего по работе делать не получается).

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

4.0. Чаще всего это презентации или прототип (как визуальный, так и возможно даже в чём-то функциональный)

4.1. В течение всего времени проекта архитектор осуществляет "надзор", ну и может по требованию тимлида/менеджера дорабатывать проект и изучать дополнительные решения или какие-то новые требования или риски.

4.2. Самое главное -- архитектор не руководит людьми, его задача чисто техническая. Он должен "смотреть вперед" чтобы Титаник проекта случайно не налетел ни на какой айсберг.

5. Что делаем тимлид/менеджер (часто это одна роль):

5.0. Он напрямую руководит людьми, распределяя им задачи, мотивируя их и потом оценивая их производительность.

5.1. Навыки тимлида: делегирования задач (кому какую задачу лучше дать), мотивирование (чтобы исполнитель делал задачу с энтузиазмом), помощь с любыми проблемами команды и коммуникация с руководством и клиентами (если есть).

5.2. Технически менеджер должен прокачивать у себя те технические навыки, которые в команде хуже всего представлены. Там, где я работал, это очень часто инфраструктура, облачные технологии и фронт-энд (но в других командах может быть совсем по-другому).

5.3. Сильно помогает опыт, просто часто с той проблемой, с которой к тебе приходят, ты уже когда-то сталкивался и что-то помнишь. Ну или ищешь сам сначала решение, пробуешь, пока команда делает то, что умеет хорошо.

5.4. Делегирование и мотивирования -- чисто психологические навыки. Нужно суметь найти правильного исполнителя и смотивировать его на решение. Очень часто (но не всегда, конечно), эту же задачу ты сам можешь решить раза в 2 быстрее, но ты не можешь тратить на неё столько времени сам, так как у тебя еще 5 таких же задач, который нужно разъяснить и смотивировать.

5.5. Как менеджер у тебя обычно 4-5 часовых митинга каждый день с разными сотрудниками, часто без зазора вообще, и нужно переключаться с одного контекста на другой очень быстро. Напонимает сеанс одновременной игры в шахматы на нескольких досках.

Показать полностью

Ответ Аноним в «Секреты вашей профессии, о которых лучше не говорить»

Не совсем наверное секреты, но с моей колокольни (опыт работы около 15 лет в компаниях разного размера, от 5 человек до огромных IT-корпораций, разные роли: разрабочик, архитектор, техлид, тимлид):

0. Про поиск в интернете. В начале карьеры соотношение "о, а я знаю как это запрограммировать" к "надо бы посмотреть, может кто уже спрашивал такое на stackoverflow" где-то примерно 20% к 80%. Где-то к 5-6 годам опыта оно инвертируется (80% понятно, 20% надо искать в интернете) и уже стабилизируется на этом уровне.

0.0. Да, даже сейчас каждый день я ищу решение в интернете не менее 5 раз в день (если я занимаюсь кодингом). И это нормально.

0.1. Регулярно (в среднем раза два в год) решение, которое я нахожу в форумах, было написано или мной, или моим шефом.

0.2. Сейчас модно использовать всякие Github Copilot или ChatGPT -- они позволяют быстро получить код, который работает на 90%. Оставшие 10% скрывают такие хитрые баги, что порой легче переписывать весь код самому, чем понять где там в коде что-то несрабатывает. Но в целом для быстрого прототипирования -- отличная вещь!

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

1.0. Его не нужно спрашивать каждый день-два о статусе. Он работает автономно, и если с чем-то затык на больше чем Х часов, то сначала он обратится к коллеге, а потом к менеджеру/тимлиду (или другому старшему товарищу).

1.1. То есть на момент его обращения за помощью, на задачу им порачено не больше Х + 1-2 часа (то есть время не сильно упущено). Х разный и зависит от проекта и команды. У меня с моим нынешним шефом это порядка 1 часа. В среднем я обращаюсь к нему один-два раза за неделю с небольшими вопросами.

2. Самый важный не-технический навык для программиста это умение печатать вслепую. Не обязательно шпарить очень быстро, достаточно просто успевать за мыслью. Моя средняя скорость где-то 350-400 символов в минуту, это примерно как быстро я думаю. По моему опыту это самый "быстро-окупаемый" навык и чем серьезнее компания и профессионал, тем меньше процент тех, кто этого не умеет.

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

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

4.0. У меня есть набор из 4-5 проверенных задач на разные технологии и темы, которые я выбираю в зависимости от кандидата. Я регулярно мониторю похожие задачи на популярных сайтах, и если вдруг задача появляется на Leetcode или где-то еще, просто меняю её (пока было один раз за 7 лет проведения интервью).

4.1. Перед тем как задачь новую (ранее мною в интервью не используемоую) задачу кандидатам в первый раз, я тестирую её на двух-трёх коллегах, с разными уровнями и опытом, чтобы понять как её будут решать люди, что видят её в первый раз. Тут же я определяю для каждой задачи "минимум", который должен выполнить кандидат (скажем поймать 2-3 таких вот особых случая, или сделать такие проверки, решение должно иметь не больше чем определенную сложность).

4.2. Для алгоритмических задач  у меня есть готовые решения на 3-4 популярных языках в интервью (в моём случае -- C#, Java, Python и JavaScript), в которые я смотрю пока кандидат решает, чтобы давать ему подсказки. Это связано с тем, что если по работе ты какой-то язык долго не используешь, то забываются детали кода решения (алгоритм обычно у них у всех одинаков, но код оптимизирован под конкретный язык).

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

4.4. В случае очных интервью, кандидат всё пишет на доске маркером. Синтаксис (в разумных пределах) тут совсем не важен. Язык тоже. Главное -- показать как ты мыслишь. Многие почему-то считают, что написать код маркером на доске намного сложнее, чем напечатать его в редакторе. На самом деле всё абсолютно наоборот!! Когда человек пишет код на доске, он не ожидает, что код запустится или даже скомпилируется. А в редакторе (мы используем codility) есть кнопка "запустить". И очень часто код не компирилируется просто по техническим причинам (например, кандидат забыл добавить нужную библиотеку) -- любой продвинутый редактор это исправит, а онлайновые в интервью это не умеют. Ну и кандидат конечно когда видит ошибку, начинает бледнеть, тушуется и приходится ему помогать -- это, бывает, смущает еще сильнее.

4.5. По итогам каждого интервью (даже просто скрининга) составляется подробный отчёт (около 2-3 страниц печатного текста). Там есть всё: краткий протокол, обязательно код кандидата и его оценка интервьюером, может быть какие-то советы другим интервьюерам на что обратить внимание (если собеседований несколько). Его видят рекруитеры и менеджеры, у которых открыта эта позиция. Мы не имеем права ничего об этом рассказывать, но рекруитеры иногда дают обобщённых фидбек кандидатам. Я сам, если кого-то тащил и не смог вытащить или уже на грани, обычно даю пару-тройку советов, что стоило бы подтянуть.

4.6. Один из ключевых принципов интервью -- это чтобы у кандидата, даже если он не получит оффер, осталось позитивное впечатение о компании и о процессе. Поэтому зачастую в какой-то момент, когда я уже понимаю, что "не вытянет", я начинаю помогать более активно (давать более прямые подсказки, из серии "а не лягушка ли это?") или писать куски кода, где случился ступор, за кандидата. Кандидат может при этом подумать, что он очень хорошо прошёл интервью, но на самом деле просто не хотелось его очень жёстко "опрокидывать". В конце концов интервью это как лотерея, многое зависит и от удачи. Пусть хорошие кандидаты приходят к нам снова!

5. В какой-то момент деньги перестают быть мотивирующим фактором (мотивирует их отсутствие). Поэтому приходится искать другие мотиваторы. Чаще всего это интересные задачи, что-то новое, на переднем крае прогресса (нейросети, IaC, трансформеры и прочее).

Постарался оставить только то, что немного подходит под понятие "секрет", остальное (более рутинное) опубликую отдельным постом.

Показать полностью

Маленькая австрийская деревушка Ебень (Eben) в регионе Понгау (Pongau)

Маленькая австрийская деревушка Ебень (Eben) в регионе Понгау (Pongau) География, Смешные надписи

Так вот где это оказывается!

Политкорректная реклама обручальных колец в аэропорту Сиэттла

Политкорректная реклама обручальных колец в аэропорту Сиэттла Политкорректность, Реклама, Английский язык

Надпись:

Его + её

Его + его

Её + её

Как стать программистом? Часть 1: А нужно ли оно тебе вообще?

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

Зачем вообще становиться программистом?

Многие решают стать программистом потому что им «нравится программировать». Однако если подобную аналогию применять, например, шире, то можно сказать, что тем, кому нравится что-то писать, надо сразу идти в писатели (а кому только читать – соответственно, сразу в читатели :-) ), кому нравится играть в футбол – сразу становиться профессиональным спортсменом, а после получения пятерки по пению – сразу рваться в шоу-бизнес.

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

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

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

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

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

Какие программисты бывают?

Если ты дошёл до этого места и всё еще думаете, что хотите стать программистом, а не, скажем, архитектором, у которого проекты новых домов создаются автоматически «умными» скриптами, или патологоанатомом, у которого написанные программы анализируют срезы и сами определяют вероятность онкологии в срезе – то у меня для вас радостная новость. Даже если ты пойдёшь в программисты, у Вас всегда есть путь в область, которая называется «прикладная информатика», где ты как раз можешь найти себе область по душе и пытаться приобрести в ней знания, для того, чтобы понимать, какие проблемы тут существуют и применять свои навыки и знания для решения этих проблем. Для обозначения этой области в русском языке используется термин «предметная область», однако в английском название у нее более говорящее – «область, в которой ты ищешь (и решаешь) Ваши задачи» -- problem domain.

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

Но и в самой информатике, или как ее обозначают на английском, «науке о компьютерах» (Computer Science), есть много направлений, где можно найти много всего интересного. Информатика сейчас переживает пору бурного развития, сходного с бурным развитием математики в 19-20-х веках: он нее регулярно отпочковываются новые интересные направления, который начинают жить самостоятельной жизнь и зачастую требовать знания из многих смежных дисциплин. Одной из последних дисциплин, которая сейчас находится на пике своего развития, например, является наука об анализе данных, data science.

Здесь важно понять, что какие-то направления менее специфичны и порог вхождения в них довольно низкий, а какие-то более специфичны и требующие большего запаса знаний. Конечно, с ростом профессионализма и сложности задач объем требуемых навыков и знаний возрастает и становится примерно равным на высоких уровнях, но на начальных, как правило, намного проще изучить программирование обычных, веб- и мобильных приложений, чем, скажем, программирование FPGA систем, микроконтроллеров или GPU. По возможности, на мой взгляд, стоит сначала освоить что-то более сложное, требующего большего запаса знаний имеющего более плоскую кривую обучения, например, программирование FPGA систем с использованием Verilog, и оценить насколько эта область тебе нравится. Для этого, как правило, требуется хорошее понимание электроники и знания об устройстве цифровых логических элементов, здесь нужны специальные программы, книги, и зачастую не самое дешевое оборудование, чтобы изучать и экспериментировать.

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

С компьютерами работают не только программисты!

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

Окончание в первом комментарии к посту (из-за ограничения размеров текста)
Показать полностью

Взгляд с другой стороны: Почему Windows 10 бесплатна в течение первого года?

(Disclaimer) Я работаю в компании Майкрософт, в подразделении поисковика Bing. Я являюсь обычным разработчиком, я не принимаю никаких стратегических решений и не имею доступа к каким-либо секретным внутренним документам. Данная статья отражает мою личную точку зрения и не является каким-либо официальным заявлением компании или публичным анонсом. Моя точка зрения может быть неполной или неправильной. Также, в виду того, что я работаю в компании Майкрософт, моё мнение также нельзя назвать независимым или непредвзятым. Вся информация, используемая в статье, основана на данных, взятых из открытых источников. (Disclaimer End)

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

Давайте разберем некоторые заявления, связанные с Windows 10.

Заявление первое: "Бесплатный сыр бывает только в мышеловке".

Обоснование: "Ведь неспроста Майкрософт впервые за 30 лет сделала Windows бесплатным. Это -- подстава! Это стратегическое средство США (и госдепа).".

Я не буду спорить: разработка операционной системы дело дорогое, затраченные на него средства должны каким-то образом компенсироваться. Самым простым способом "компенсировать" такую разработку является классическая продажа ОС как обычного продукта, как Майкрософт это делала последние 20-25 лет. Пусть финансисты рассчитают предварительно сколько людей её купят, определят уровень продажной цены с учетом всех расходов на ее создание, на рекламу, учитывая проценты дистрибьютерам и так далее, после чего заложат в цену ожидаемую прибыль компании и начнут продажи. Майкрософт это делала уже с каждой предыдущей версией и здесь нет ничего нового -- старая модель, предсказуемая (если финансисты не ошибутся) прибыль и результаты.

А давайте здесь просто на три минуты отвлечемся от Windows 10 и перенесемся в 1984 год. Именно этот год был для Майкрософт переломным: до этого компания занималась выпуском практически исключительно языков программирования (в основном Бейсика). И тут, неожиданно, разозленная успехом Apple, Atari и Sinclair на рынке персональных компьютеров, большая рыба в виде IBM тоже решила показать who is who и представила свой первый персональный компьютер. У IBM было на тот момент больше 60 лет опыта продажи "больших" компьютеров (тех, что мы сейчас называем mainframes), но в "потребительском" сегменте у них не было еще опыта. Аналитики компании проанализировав рынок сделали вывод: в отличие от mainframes, где компьютер продавался просто в виде железки и весь софт ставился уже своими программистами (включая и операционные системы, часто доработанные под определенные архитектуры и задачи), "персональный компьютер" (как его назвали маркетологи) требует предустановленного программного обеспечения (ПО) для работы. Это ПО мы сейчас называем операционной системой (ОС).

IBM заключило контракт с Майкрософт о подготовке интерпретатора языка Бейсик для этого компьютера. В ходе переговоров представители IBM спросили у Билла Гейтса не знает ли он компанию, которая могла бы поставить ОС для нового компьютера. Билл Гейтс предложил одну фирму, которая в то время занималась адаптацией уже устаревающей ОС CP/M под различные платформы. Однако, когда делегация от IBM совместно с Intel приехала подписывать документы о поставке новой ОС, глава фирмы просто предпочел не изменять своего расписания в этот день и отправился на целый день летать на собственном частном самолете, а принять гостей оставил свою жену. Жена, я так понимаю, не в самом лучшем состоянии духа, оказала им такой "радушный" прием, что компания категорически отказалась иметь дело с этой фирмой.

И тогда, по воле случая, Майкрософт перенял контрактные обязательства по поставке ОС. Это был их первый продукт в этой области: все-таки написание ОС сильно отличается от написания языков программирования! Они были вынуждены работать днями и ночами чтобы успеть, и первый их продукт, конечно, был далек от функциональности ОС для mainstreams. Но они заключили договор с IBM по которому за Майкрософтом оставались права на ОС, в то время как IBM лицензировала этот продукт у Майкрософт и платила ей отчисления за каждую установленную копию.

Сейчас, через 30 лет, когда описывают этот эпизод, очень часто ему дают такую оценку: "Билл Гейтс был хитер и заставил IBM подписать такой выгодный для Microsoft контракт". Но как так получилось, что 28-летний никому не известный ботаник-программист, глава маленькой фирмы заставил подписать контракт такой гигант как IBM, да еще и для не выгодных для последнего условиях?

На самом деле всё очень просто. IBM как гигант с огромным опытом продажи компьютером относился к ПО для своих компьютеров примерно также, как если бы компания Boing при продаже самолётов давала каждому пилоту бесплатную бейсболку. То есть это были "семечки", что-то не важное -- ведь их бизнес был продажа дорогих и сложных компьютеров. ПО и его рынок до того моменты были вторичными, они только обслуживали основной рынок продаж компьютеров и запчастей к ним. Для IBM Майкрософт был просто одним из субподрядчиков, «вендоров», с которыми IBM заключает тысячи контрактов. Поэтому неудивительно, что на презентацию своего нового компьютера перед публикой никто из IBM даже не подумал позвать представителя Microsoft... (кстати, в тот день Гейтс как раз целый день был на переговорах в Apple, но это уже другая история).

Попробуем найти аналогию между 1984 годом и сегодняшним днём. Тогда IBM просто не смогла увидеть, что одновременно с появлением рынка персональных компьютеров появится еще больший рынок ПО для компьютеров и со временем стоимость ПК станет где-то сравнима со стоимость ПО для этих компьютеров, а где-то даже намного меньше. Именно это и привело бурному росту компании Майкрософт, которая первым поняла важность этого рынка и стала активно на нем работать.

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

Если раньше для создания и редактирования документов нам нужно было покупать программный продукт Microsoft Office, то теперь для того, чтобы получить услугу по созданию и редактированию документа мы можем воспользоваться либо Google Docs, либо Microsoft Office 365, либо другими платформами, где нет необходимости покупать программу, устанавливать ее, активировать так далее.

Если раньше мы покупали жесткий диск, чтобы сохранить фотографии, то теперь продвинутые пользователи покупают место в облачных хранилищах типа OneDrive, DropBox, GoogleDrive и так далее. Таким образом и рынок hardware и рынок ПО постепенно схлопываются на рынке услуг, или как их называют в англоязычном мире, «сервисов» (services).

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

Если для офисных программ такое еще более-менее подходит – именно так сейчас и работает Office 365 от Майкрософта – то за такие услуги, как электронная почта, сервис мгновенных сообщений, социальные сети пользователи не привыкли платить. Представьте себе, что за каждый посланный е-мейл Вам нужно будет платить, скажем, 3 копейки – будете ли Вы пользоваться таким сервисом? Возможно – да, кого-то это устроит, если это обеспечит большее качество услуги, чем «традиционная» электронная почта – но большинство просто останется на бесплатном сервисе. А представьте, если нужно будет платить за каждый пост и каждую размещенную фотографию в Одноклассниках, ВКонтакте или Фейсбуке?

«ОС как сервис» понятие еще очень молодое и новое, большинство пользователей еще не привыкло так воспринимать Windows. Однако Майкрософт, на мой взгляд, понимает, что рано или поздно такое время придёт и именно этим и объясняется один из фактов бесплатности новой ОС. К вопросом её монетизации и сбору телеметрии мы еще вернёмся и подробно это обсудим!

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

Вопрос, конечно, очень провокационный. Потому что если кто-то для себя сможет ответить на него «да», то следующим логичным вопросом будет «а есть ли разница куда мне поставить браузер: на Windows 7, что я купил еще пять-шесть лет назад, на Windows 8, на которую я обновился, или может быть на бесплатный дистрибутив Ubuntu, что сосед скачал и записал мне на болванку?».

(продолжение по техническим причинам в первом комментарии)
Показать полностью

Просьба к админам: добавьте счётчик символов к полю текстового поста, чтобы не больше не было обрезанных постов

Ничего программировать не надо, в посте уже есть готовое решение, достаточно сделать просто замену одного куска HTML на другой
Просьба к админам: добавьте счётчик символов к полю текстового поста, чтобы не больше не было обрезанных постов Ничего программировать не надо, в посте уже есть готовое решение, достаточно сделать просто замену одного куска HTML на другой
Показать полностью 1

Педиатр-программист: Как я попал в Майкрософт | " Работа в Майкрософт Бинг изнутри", часть 7 из 7 (пост 3)

Часть 1: Поворот
Часть 2: (лирическое отступление) Школа и медвуз
Часть 3: Microsoft Student Partners Germany
Часть 4: Подготовка к интервью
Часть 5: Интервью (пост1) (пост2)
Часть 6: Практика в Майкрософт Бинг в Сан-Франциско (пост1) (пост2)
Часть 7: Работа в Майкрософт Бинг изнутри (пост1) (пост2) (пост3)

Для связи используйте мой ник здесь и Гугл :)
---------

Вообще задача твоего менеджера – это стимулировать тебя работать лучше и качественнее. Это совсем не значит, что ты должен работать больше! Вовсе нет. Ты должен работать более охотно, ты должен быть сам более заинтересован в работе, чтобы, приходя на нее утром, у тебя не было необходимости раскачивать и думать «ну вот опять надо делать Х», а вечером постоянно смотреть на часы и спешить домой. И достичь этого совсем не так просто.

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

Вот несколько примеров. Мы все по образованию инженеры-программисты, то есть в дипломе стоит что-то software engineer. Один из команды захотел специализировать в области data science (чем мы то, в принципе, как команда и занимаемся – только из нас напрямую никто этому и не учился). Вместе с менеджером они выбрали подходящий курс в Стенфорде (благо он тут под боком, но там можно и онлайн), и парень вот получает там уже второй сертификат и работает очень много в проектах, где требуется нетривиальный анализ данных (data mining, machine learning и прочее).

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

Кому-то просто дали в качестве рабочего лаптопа MacBook Pro и проекты, связанные с операционной системой от «яблочной» компании, и это было уже достаточным мотиватором, чтобы человек загорелся и стал работать еще больше, чем работал.

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

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

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

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

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

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

Это, казалось бы, простое испытание – просто забыть свои амбиции, свои оценки в ВУЗе, какой ты был крутой и сколько олимпиад или соревнований выиграл – и стать для начала простой «рабочей лошадкой» -- оно дается тоже не всем.

Я видел много разных историй успеха, и что удивительно, успешные люди спустя какое-то время становятся похожи друг на друга: успех как бы притягивает дальнейшие успех. Но вот путь до этого у многих отличается. Кому-то, как, например, Scott Guthrie, одна компания – это все что нужно для успеха. А кому-то, как Яну Куму (родившийся и выросший недалеко от Киева), нужно, чтобы тебя отверг Facebook (а твоего друга еще в придачу и Twitter), для того, чтобы создать собственную компанию и стать миллиардером.

=====================

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

Мне нравится американская традиция в длинных и запутанных докладах в конце формулировать кратко в виде одного предложения самый главный вывод. Этот вывод называется очень красиво take home message («сообщение, что Вам нужно взять домой»). Так вот, take home message этого длинного текста очень прост: никогда, запомните, никогда не поздно стать хозяином своей судьбы, изменить себя и начать жить так, как Ты этого хочешь и как Тебе нравится. Это – высшая свобода, которую мы можем получить в этой жизни, и нет ничего ценнее в этой жизни, чем это.

(КОНЕЦ // The End)

Я беру небольшую паузу до сентября, чтобы вернуться с постами о том, что такое современная информатика и с какого бока правильно вгрызаться в этот кусок гранита: это самый частый вопрос, который мне задают и в комментариях, и в личной переписке. Ждите. Надеюсь, вам понравится. ;-)
Показать полностью
Отличная работа, все прочитано!