Отказ от ответственности
Относитесь к следующему блогу как к художественному роману. Как? Не принимайте это за чистую монету и просто представьте себе мир, в котором все это возможно. Наслаждайтесь блогом.
! isAProgrammer ()
да. Вы правильно прочитали. Я действительно не программист. Знаю, знаю ... В моем резюме написано, что я программист. Здесь также упоминаются все языки программирования, которые я знаю. Я даже постоянно веду блоги, в которых обращаюсь к программированию или связанным с программированием концепциям. У меня есть степень, я кодирую каждый день, и даже мои личные проекты почти всегда связаны с кодом.
«Хватит ненужного введения наполнителя и уже перейдем к сути», вы правы, я обычно добавляю ненужную болтовню в начале своих блогов, чтобы сделать его немного драматичным, но позвольте мне сразу перейти к нему.
Вот уже несколько десятилетий (?), Когда кто-то думает о программистах, они думают о быстро меняющихся строках компиляции. Терминалы. Если заявления. Для петель. Темно-тематические IDE. «Это не ошибка, это особенность». Или, может быть, даже это
Мне всегда не нравился этот рассказ. Повествование о программисте, который является просто программистом. Итак, я пишу этот блог, чтобы прояснить, то, что я думаю, является устаревшим представлением о том, как мы определяем разработчиков программного обеспечения в современной индустрии.
Проблемный процесс
Мне нравятся мысленные образы, поэтому давайте сделаем небольшое упражнение. Представьте себе это. Кто-то претендует на новую работу. Первый шаг - пройти простое собеседование, лучше узнать человека, увидеть, чего он хочет от своей потенциальной новой работы. Легкий. Простой. Второй шаг (обычно) - это личностный тест. Ооооо, этот тест личности. Кандидату предоставляется один из множества общих тестов, найденных в Интернете, чтобы позволить алгоритму определить, что он за человек, вместо того, чтобы определять это на самом деле. Я имею в виду, общеизвестно, что машины лучше чувствуют, что такое человек, чем сам человек. Человек получает обратно один из многих заранее определенных результатов и соотносит себя с любым результатом, который он получил. Базовая психология. Мы склонны видеть себя в вещах. Если алгоритм затем решает, что человек соответствует культуре компании, кандидат переходит к тесту по кодированию, который является важной частью процесса. Затем кандидат либо получает короткую дополнительную сессию, чтобы обсудить код, либо он просто получает прямое "да" или "нет".
А теперь давайте возьмем того же разработчика и поместим его в реальный рабочий сценарий. Из упомянутого выше процесса знаете ли вы, как этот разработчик будет действовать под давлением? Вы знаете, как этот разработчик отреагирует, если он что-то застрял и не может решить? Вы знаете что-нибудь об их мыслительном процессе? Ты знаешь как…
они решают все эти проблемы?
Бинарная музыка
Вот мои сомнения. Моя проблема не в самом процессе, моя проблема в чертах, которые процесс пытается выделить. Почти на всех этапах оценки кандидата самая важная черта, которой должен обладать разработчик, на мой взгляд, не проверяется. Что вы спрашиваете? Мыслительный процесс кандидатов при решении проблем. Я имею в виду, подумайте об этом. Все, что мы делаем при разработке программного обеспечения, сводится к следующему: «У нас есть проблема, как решить ее с помощью кода?». Независимо от того, говорим ли мы о простом приложении-калькуляторе или о полноценном API, все сводится к тому, как мы решаем решить возникшую проблему.
Установив эту концепцию, концепцию, согласно которой решение проблем является ядром того, что мы делаем в программировании, почему мы не оцениваем как решает человеческая проблема? Мыслительный процесс? Иногда к этому обращаются на последующих собеседованиях после проверки кода, но всегда кажется, что этот шаг немного разбавлен по сравнению со всеми предыдущими. Но я заметил, что в этом интервью люди с большей вероятностью сообщают как, что они реализовали, а не почему . Фраза «Я сделал это, потому что…», «почему», в конечном итоге дает нам исходную точку зрения, которую я сделал о том, как человек решает проблему.
Но худшее и, безусловно, худшее, что я видел в этих оценках, - это люди, которых полностью отвергают. Я постараюсь сохранить это как можно более безумным, потому что я могу написать совершенно новый блог именно на эту тему, так что вот моя точка зрения.
Хорошо написанное приложение не означает, что вы хороший программист, а плохо написанное приложение не означает, что вы плохой программист.
Давай, освистай меня, сколько хочешь. Я уже могу представить ваше лицо, говорящее «ЧТО ?!», но позвольте мне объяснить. Мы живем в эпоху, когда знания очень легко доступны. Кто-то может найти именно то, что ищет, с помощью одного простого поиска. Не поймите меня неправильно, их код может быть безупречным, но знают ли они почему безупречный? Знал ли этот человек, почему этот подход используется большим количеством людей? Рассматривали ли они другой подход? Почему они не выбрали другой подход? Я скажу вам это сейчас, и я даже процитирую это, чтобы вы могли использовать это для аргументации против противоречивых мнений, которые я мог бы высказать позже:
Я бы предпочел работать с кем-то, кто написал посредственное присвоение кода, но может поддержать свой мыслительный процесс и желает научиться кодировать лучше, чем с кем-то, кто написал «феноменальное» присвоение кода, но не может объяснить, почему проблема была решена именно так. взялся.
Если только ты не…
git push --force origin master
Тогда нам нужен серьезный разговор
Помимо шуток, эта ошибочная оценка того, как измеряются навыки разработчиков, превращается в кроличью нору с нелепым эффектом домино внутри компании. В качестве примера приведу небольшую пародию, наслаждайтесь:
A: «Эй! Я просматриваю ваш PR прямо сейчас, и я нашел то, о чем хотел вас спросить »
B: «* о, вот и мы снова, * конечно же! Как дела?"
A: «Я заметил, что вы использовали ‹insert_inefficient_data_structure› вместо ‹insert_efficient_data_structure› , это очень интересный подход»
B: Да, совсем другое, правда?
A: О да, я бы тоже наверняка использовал другое слово! * У него ужасная временная сложность *. Мне было интересно, почему мы не выбрали ‹insert_efficient_data_structure›?
B: Ну, вы знаете, ‹insert_inefficient_data_structure› выполняет свою работу, я делал это несколько раз раньше, и многие другие тоже этим пользуются!
A: Я имею в виду, что да, код работает, поэтому я предполагаю, что он выполняет свою работу, но типа, почему, хотя? Может быть, это сделали другие, но хотим ли мы это сделать?
B: Это… подходит для наших нужд!
О: На самом деле, главное преимущество нашего приложения - это его скорость. Я имею в виду, что весь слоган нашей рекламной кампании звучит так: «Вы знаете, какое приложение вы используете? Наш однозначно быстрее! Мы направим все наши инженерные знания исключительно на достижение этой цели. Это обещание! " Это… Это имеет временную сложность O (n²). В то время как другой имеет O (logn). Учитывая проблему, которую мы пытаемся решить (посмотрите, что я там сделал?), Я думаю, что лучше использовать другой, менее сложный, но более быстрый и подходящий подход в нашем приложении.
B: Ммм ...
A: * PR закрыто *
Это показывает, что мыслительный процесс, который вошел в эту реализацию, был, ну, ну никаким, что кощунственно, потому что мыслительный процесс программиста священен. Это почти можно сравнить с написанием музыки. Они оба берут компоненты, которые ничего не значат, когда они автономны, но когда все они собраны вместе, они растворяются в одном, изысканном, уникальном результате, который служит определенной цели. Будь то музыка, в которой вы стремитесь передать определенное чувство, или программирование, в котором вы стремитесь ... решить проблему, цель, которой они стремятся служить, должна быть тщательно спланирована, хорошо продумана, преднамерена и только в случай программирования, логичный.
Чтобы поднять настроение и перейти к завершению, вот отрывок того, как я иногда пишу код с нуля.
Желе с арахисовым маслом
Все сводится к тому, чтобы заглянуть в будущее и представить, с какими коллегами вы хотели бы работать. Лично я, когда дело касается коллег, предпочитаю работать с проблемными гуру. Для меня гуру проблем - это тот, кто может обнаружить проблему, проанализировать ее, критически обдумать решение, а затем наступает часть кодирования. Я хочу работать с кем-то, кто не просто занимается программированием.
Но затем идет часть: «Хорошо, как мы можем решить эту проблему, чтобы подчеркнуть способность программистов решать проблемы, не сосредотачиваясь исключительно на строках кода?». Во-первых, я хочу уточнить, что отрасль постепенно переходит к этому. Между всей сатирой и аргументами, которые я привожу, есть ощущение признания того, как развивается отрасль. Но вот мое предложение, и это одно слово:
Я люблю псевдокод. Блин, блин! Я думаю, что псевдокод - это идеальная гармония для демонстрации того, насколько хорошо думает разработчик, а также насколько хорошо он потенциально мог бы написать это в коде. Эта комбинация - бутерброд с арахисовым маслом в мире оценивания программистов, и это предложение, которое я никогда не думал, что буду записывать!
По сути, нам нужно изменить мета. Мета оценки программиста того, насколько хорошо он кодирует, и только насколько хорошо он кодирует. Для разработчиков есть гораздо больше, чем просто перевод предложений на инко-английском языке в машинно-дружественной манере. Давайте вместе исследуем этот потенциал как целую отрасль. Помимо того, что я предложил, я не знаю, как это можно сделать, что является иронией, поскольку я только что сказал, что мы все должны стремиться к тому, чтобы решать проблемы. Но это то, чем мы можем заняться вместе. Разработчики, рекрутеры, менеджеры, владельцы продуктов, скрам-мастера, все. Потому что, нравится вам это или нет, тип разработчика, который у вас есть в вашей команде, будет играть важную роль в определении успеха этого проекта.
Это все, что у меня есть для тебя! Если у вас есть какие-либо мысли по этому поводу, давайте обсудим! В остальном, удачного кодирования! (или это счастливое решение проблемы, а?)
