Самый важный навык программиста.

Привет! В этом посте поделюсь своими мыслями по следующим вопросам:

1. Что самое сложное в работе программиста?
2. Какой скилл является самым важным?
3. Куда расти: вглубь или вширь?

В программировании способов реализовать какую-то задачу — вагон и маленькая тележка.

И представьте: собралась команда разработчиков, и им нужно реализовать какой-то большой проект. В этой команде могут быть как новички, так и древние мамонты. Новички учились по туториалам и никаких других способов реализовать задачу не знают. Ну а древние мамонты могут быть тоже разные. У одних расцвет сил пришёлся на времена Java 1.0, и в голове могут быть крутые, но чуть устаревшие знания. А могут быть и крутые мамонты, которые решают задачу элегантно: ты смотришь на их код и думаешь: «Боже, как круто! Как круто и непонятно».

Всё это многообразие умов как-то договорилось программировать совместно. Вырабатываются некоторые договорённости и гайдлайны: начиная с выбора фреймворков, заканчивая тем, парсить ли DTO в сервисах или всё-таки в контроллерах.

Проект живёт, кодовая база растёт, люди уходят и приходят.

И в какой-то момент появляешься ты. Ты проходишь онбординг, настраиваешь IDE, получаешь доступы, скачиваешь проект и такой:

«Господи, что это такое?!»

Ты видишь столько кода и не понимаешь — это говно или так надо по объективным причинам. А если ты новичок, то смотришь на говно и думаешь, что это апогей алгоритмической мысли.

И если ты не сидел в проекте со времён распада СССР, то самым сложным в твоей работе будет одно:

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

И чем сложнее задача, тем больше времени придётся тратить именно на это: на чтение и понимание чужого кода. Умение разобраться в чужом коде — это навык, который будет использоваться 88% твоего рабочего времени.

Это самое сложное, но, на мой взгляд, не самое важное в работе программиста.

Что же является самым важным?

Написать свой код так, чтоб спустя годы тебя не прокляли. А ещё лучше — чтоб не прокляли в тот же миг.
Тебе может показаться, что твой код проходит ревью, и, как бы, «старшие коллеги» берут часть ответственности на себя за то нечто, что породил ты в больном бреду, пытаясь понять, как оно всё тут принято. Но это далеко не всегда так. Ревью делают такие же люди как и ты. И ты будешь делать ревью и ловить себя на мысли, что хочется поставь аппрув "ради галочки", вроде бы все тут хорошо....

Если ты программируешь уже какое-то время и даже писал пет-проекты, то, возможно, замечал: возвращаясь спустя время к своим старым проектам, ты задумчиво чешешь свою репу и думаешь: «Господи, это же я писал, почему я ничего не понимаю?!». А это только ты, в маленьком проекте. Помножь эту ситуацию на бесконечность — и получишь некоторое (хоть и не полное) представление о том, что тебя ждёт, если ты не научишься писать код МАКСИМАЛЬНО ПРОСТО И ПОНЯТНО.

Это и есть самое важное — уметь писать понятный код. Не только тебе, но и другим людям.

Как к этому прийти?
Нет быстрого способа. Нужно породить тонну говна и с опытом обрести понимание того, «что такое хорошо, а что такое плохо».

Ну и куда расти?

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

Но это и не нужно. Благо, несмотря на всё это многообразие, под капотом везде заложены одни и те же принципы, которые придумали «когда наши родители были молодыми» люди, которые в разы умнее самого умного твоего знакомого.

Если у тебя получится хорошо (плюс-минус) разобраться в какой-то одной технологии, то освоить другие не составит большого труда. Поэтому моё имхо: не нужно бросаться учить всё подряд. Всё не выучить. И не угадать, что надо учить.
Сосредоточься на чём-то одном и долби в эту точку. А остальное поймёшь по ходу.

Всем добра, хорошей пятницы и прекрасных выходных!