10 советов, как стать самым ужасным разработчиком

Перевод статьи «Top 10 Pieces of Advice for Becoming the Worst Developer Possible».

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

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

Чтобы собрать нужную информацию, несколько недель назад я опубликовал твит, в котором задал разработчикам простой вопрос:

Какой совет вы дали бы начинающему программисту, чтобы помочь ему стать максимально ужасным разработчиком?

В этом посте я собрал десятку ответов, которые понравились мне больше всего, и дополнил их собственными комментариями и советами.

10. Прежде чем приступать к кодингу, вы обязательно должны освоить 100% JavaScript

Это отличный совет, и конечно, применим он не только к JavaScript. Не делайте ничего, пока не станете экспертом № 1 по этой технологии в вашей стране или хотя бы в кругу знакомых. Как еще быть уверенным, что не накосячишь? Как иначе работать, не опасаясь насмешек?

Если начать слишком рано, можно допустить ошибку. А ведь разработчики никогда не допускают ошибок: работа у них такая.

9. Никогда не подвергайте сомнению слова лидеров мнений. Они всегда правы и, разумеется, умнее вас

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

Помните: 1 подписчик === 1 миллиард клеток мозга. У вас есть триллионы клеток мозга? Вот то-то же.

8. Если вы чего-то не понимаете, виноват создатель языка и сам язык. Чтобы это исправить, придется написать собственный язык

У нас так много багов только потому, что у нас просто мало языков программирования. Брендан Эйх создал JavaScript за 10 дней. Разумеется, у вас все получится гораздо лучше, если вы уделите этому чуть больше времени, скажем, месяц. Что вас останавливает?

7. Если кто-то предлагает решение, альтернативное вашему, просто спросите: «А как насчет <безопасности, масштабируемости, ортогональности, поддерживаемости>?», а потом просто уйдите

Никто, кроме вас, не может на самом деле понять ваш код и причины, по которым он был написан именно так, а не иначе. Не ждите, что кто-то даст полезный фидбэк; в 110% случаев человек вообще не понимает, о чем говорит. Если бы окружающие были действительно умны, они написали бы этот код так же, как вы.

6. Не изучайте HTML, он уже устарел

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

Также не забывайте встревать в любой разговор, где обсуждается HTML, и напоминать всем, что HTML это не «настоящий» язык программирования. То же самое касается CSS. Вставьте ссылки на эти обсуждения в свое резюме, чтобы менеджеры по найму знали, что вы — «настоящий программист».

5. Не зацикливайтесь на коммуникации с людьми. Люди не имеют значения, важны только компьютеры!

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

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

4. Старайтесь усложнить все как можно больше. Это залог того, что вы сохраните работу

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

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

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

3. Копируйте все из интернета, и не важно, понимаете ли вы скопированное

Ваша цель — выдавать на-гора код. Благодаря многочисленным ресурсам, таким как Stack Overflow и Google, у вас есть практически все ответы. Проблема в том, что многие разработчики зря теряют время, пытаясь разобраться в явно рабочем коде. Если все работает, просто идите дальше и не тратьте время на обдумывание.

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

2. Ваше мнение — единственное, к которому нужно прислушиваться

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

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

Этот совет — самый важный, и в дополнительных пояснениях не нуждается.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Прокрутить вверх