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

Итак, что же еще нужно сделать:

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

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

Как известно, если ты серьёзный программист, синтаксический сахар тебе не нужен, это баловство. Ещё несколько лет назад Python считался детской погремушкой именно из за этого. Чем вам фигурные скобки мешали? Ребячество какое-то придумали: заменить фигурные скобки на отступы табуляции. Сказал солидный дядя. Маличики согласно покивали, виновато глядя в потолок. Через год все работали в коллективах где Питон основной язык.

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

Перевод статьи Seven Deadly Sins of a Software Project автора Yegor Bugayenko.

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

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

Некоторые из них напрямую или косвенно связаны с когнитивными искажениями человеческого сознания – в этих случаях я даю ссылки на соответствующие вики-статьи. Также интересен список известных когнитивных искажений.

1 Преждевременная оптимизация

В 97% случаев надо забыть об эффективности малых частей программы: преждевременная оптимизация – корень всех зол. Но в 3% случаев об оптимизации забывать не нужно.
Дональд Кнут

Хотя никогда зачастую лучше, чем прямо сейчас
Тим Питерс, Зен языка Python

Что это

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

Почему плохо

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

Как избежать

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

TL;DR Golang был разработан специально для того, чтобы расцвести в больших проектах, которые пишут большие группы программистов разных уровней, и в мире нет такой группы больше, чем open-source сообщество.

Абсолютно всё в жизни основано на компромиссах — первый закон термодинамики доказывает это, и языки программирования тут не исключение. Компромиссы в Go не уникальны, но именно благодаря их удачному сочетанию, Go и случился. Законы физики также утверждают, что каждое действие порождает противодействие, и, с ростом популярности, также возрастает количество критики в адрес языка, иногда обоснованной, иногда не очень. Позвольте мне объяснить, почему я считаю, что эта критика не важна, и Go обречён на успех несмотря ни на что.

За последние 7–8 лет наши сотрудники прочитали около 2000 резюме UX-проектировщиков. Отсобеседовали — под сотню. Пару десятков приняли на временную или постоянную работу. А параллельно пережили неисчислимое количество однотипных бесед с теми, кто «тоже хочет» (или делает вид, что хочет) заполучить себе в команду подобного специалиста.

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

Попробуем немножко расшатать самые распространенные мифы. Вдруг это кому-то поможет подойти к вопросу найма UX-проектировщика чуть более рационально и эффективно.

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

Человека, который ввёл этот термин в 2010 году зовут Шон Эллис (Sean Ellis), CEO компании Qualaroo.
И вот как это было:



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

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

Прочитали? Дальше будет про лучший в мире язык программирования, который я назову ближе к концу. Да, да, еще три дня назад я и не думал что единороги существуют — ведь каждый язык так или иначе сосет, и каждый сосет по-своему (хотя нет, есть и такие которые сосут всегда и везде, но о них не будем). Как инженер, я прекрасно понимал что в вопросе языка не возможно без разнообразных trade offs, начиная с garbage collected vs manual memory management, хотя Rust пытается съесть рыбку не присев на палку в этом вопросе, и так далее. Хоть мы и говорим о языках общего назначения, все они так или иначе позиционируют себя, фокусируясь на каких-то идеях, принципах, и целях, в которых они хороши, оставляя все не согласованное с такими принципами в лучшем случае возможными, но не эффективными и/или не удобными. Одним словом нецелесообразными. Однако язык, сочетающий в себе несочетаемое, есть.

Первая часть здесь. Продолжение:

Семь долбаных лет я ждал язык, который хоть как то ответит части моих желаний. За это время, и в фоновом режиме я препробывал всё. Всё — означает, всю херню общего назначения, и всю херню не совсем общего назначения. Нельзя прочувствовать язык только что-то прочитав про него и написав Hello World. Чтобы понять — надо хоть немного попрограммировать — написать какую нить вещь. И вот все это время, я в минуты отчаянья качал какой-нить “замечательный язык”, и пытался что-то написать. Какие-то вещи даже до сих пор крутятся в конторе (или крутились).

Дискуссии о текущем положении C++ в мире программирования, как правило, делят участников на два фронта: одни этот язык недолюбливают, пророча ему скорую гибель; другие же наоборот утверждают, что на C++ писали, пишут и будут писать. Я бы сказал, что истина находится где-то посередине, но это означало бы, что C++ находится в неком «подвешенном» состоянии, в котором он был, например, между выходами стандартов C++03 и C++11. На самом деле всё обстоит немного иначе. Как? Давайте попробуем в этом разобраться.

Доброго времени суток, хабр!

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



Мы будем использовать их вместе!

Последняя пятница апреля не стала исключением для встречи сообщества любителей языка Python. В этот раз спикеры на Python Meetup поделились следующими темами:

• Grail: шаги для ваших Python-тестов
• Rest сервисы на Flask
• GUI приложение за пять минут

Видео и ссылки на презентации под катом. Приятного просмотра!

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

Разработка игр – одно из самых перспективных направлений в современном мире IT. Сегодня мы решили поделиться с вами подборкой самых востребованных, популярных и, что немаловажно, бесплатных курсов Microsoft, связанных с разработкой игр. Пять избранных курсов ждут вас под катом!

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

Привет, друзья!

По результатам статьи «Как мне стать project manager’ом в IT, если до этого я работал(-а) на похожей позиции, но не в IT?» возникли вопросы, а что же делать Team Leads (TL), которые уже работают в IT? Как этим Team Leads стать руководителями проектов? В данной статье намеренно не будет упоминаться позиция Tech Lead, которая в моем понимании ничем не отличается от Team Lead, с точки зрения роста из нее в PM. Таким образом сокращение TL можно читать как Team Lead, так и как Tech Lead.

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

Если после прочтения данного вступления вы все еще считаете, что вам почему-то все равно необходимо вырасти из TL в Project Manager’а, и вы готовы вкладывать время и силы в свое развитие — welcome читать дальше. Если вы не готовы вкладывать в себя и учиться, практиковаться, учиться и снова практиковаться — дальше читать смысла нет. Не тратьте свое время.

Чтобы избежать некоторой путаницы, стоит упомянуть, что разбираю в этой статье только вариант «TL->PM». Опцию «Инженер->TL» не рассматриваю для сокращения объема статьи.

Кадр из фильма Kingsman

Уверены, в этой статье вы точно узнаете своих сотрудников, а возможно, и себя. Шведский предприниматель и разработчик Дэвид Эльбе описал восемь типов программистов, с которыми ему приходилось иметь дело за последние 10 лет работы в проектах по веб-разработке. Какие типы лучше всего объединить в команду и какой код от них ждать — читайте в переводе от Alconost.

1. Агент 007

Кадр из мультфильма “Пингвины Мадагаскара”
Быстро вникает в ваши проблемы и решает их. Не очень заботится о качестве кода. Ему не придет в голову исправлять отступы в чужом коде. Если необходимо, «воспользуется скотчем».

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

Если такой сотрудник уволится, будет трудно исправлять проблемы во всем приложении. Всегда выдает результаты быстрее, чем от него ожидают. Заказчики и менеджеры без ума от него.

Плохо срабатывается с Перфекционистом.