Всем привет!

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

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

Если у вас есть какие-то значимые правки в PR - лучше сразу созвониться, нежели объяснять все текстом.

Знаю, что очевидно. Но много людей так не делают.

В моем случае это было связанно с тем, что я сделал большую задачу с улучшением TS, однако не все коллеги знали об этом.

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

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

Договорился созвониться с 2-я коллегами, там уже на встрече ребята сами признались, что ничего не поняли и восприняли все эмоционально.

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

#devtips #work

Всем привет!

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

Знаю, что холиварная тема, но спрашивают в комментах, так что решил сказать свое мнение.

Лично я считаю, что это нужные навыки, но их не стоит специально учить. По крайней мере в начале.

Да, вы можете сказать, что есть подсказки в ide, нужно писать код, а не текст и тд. Думаю все слышали эти аргументы сотни раз.

Но вопрос скорее в другом, если ты сидишь за компьютером 8+ часов в день, не стоит ли научиться использовать его максимально эффективно?

Шорткаты OS и IDE, слепая печать, работа в терминале и тд.

Без всего этого можно спокойно обойтись, но стоит ли?

Да и в целом, на работе обычно нужно много коммуницировать, так что тут тоже этот навык будет полезен.

Ок, Айюб, а как ты научился слепой печати?

Я просто нашел совет в интернете, что нужно начать писать 10 пальцами и тыкать каждым правильные клавиши. А в слепую печатать уже дальше сам научишься.

В целом, так и вышло. В начале я писал раза в 3 медленнее. Но после недели уже пальцы привыкли, и начал писать на той же скорости. Через 3 недели заметил значительное увеличение в скорости.

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

Всем хорошего вечера!

#devtips #work

Всем привет!

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

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

Однако недавно наконец осознал то, насколько все это не удобно, особенно когда нужно записывать видео.

У меня обычно максимальная креативность/продуктивность в утреннее время. А пока встанешь, оденешься и дойдешь до коквркинга, состояние уже не то.

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

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

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

Так что всем советую обустроить удобнее рабочее место. Сам теперь жалею, что не сделал это раньше.

#devtips #work

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

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

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

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

#devtips #work

Всем привет!

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

Ответа тут единого нету, но в большинстве случаев — это нет.

В каких случаях я считаю, что можно делать тестовое:

1) Вы ищите первую работу, либо у вас пока очень мало опыта. Часто в качестве фильтра компании дают тестовое, если других вариантов нету — то можно попробовать и сделать.

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

3) Предоставленное задание вам реально интересно и вы хотел бы его сделать.

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

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

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

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

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

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

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

#devtips #work

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

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

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

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

В общем, не попробуешь — не узнаешь, но пока выглядит, как что-то интересное. А что вы думаете по этому поводу?

P.S. Порадовало, что у данной статьи только один тег “backend”)

https://engineering.atspotify.com/2023/05/tv-spatial-navigation/

#devtips #work

При общении с подписчиками часто вижу, что они не довольны своим развитием.

И зачастую причиной плато является плохая работа.

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

Почему?

Да по той просто причине, что это большая редкость.

Даже если вы и попадете в такую среду, то более чем уверен, что ваши ожидания не оправдаются.

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

Наверное окончательно все на свои места встало, когда я попал в Яндекс. Где как не там должны быть эти супер разрабы?

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

Да и в конце концов вас никто нянчить же не будет. Максимум совет где-то даст либо подскажет более хорошее решение.

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

Так что не стоит совершать мои же ошибки и винить внешние обстоятельства.

А вместо крутых коллег лучше подыскать сложные задачи, которые вы на данный момент не знаете, как решать.

#devtips #work

Всем привет!

Под мои недавним постом о развитии на работе было много обсуждений. Однако хотел бы сфокусировать свое внимание на self review (само проверке) кода.

Для тех, кто никогда так не делал, это все может показаться странным. Кажется, на что там смотреть, если я и так все помню?

Однако если научится снимать менять роль и смотреть на свой pull request со стороны — то можно заметить очень много недочетов и избавится от лишних комментариев.

Наверное самым простым способом будет провести ревью где-то через день. А не сразу после завершения задачи.

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

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

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

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

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

В целом, навык самоанализа полезен во всех сферах жизни.

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

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

#devtips #work

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

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

Основная проблема, которую я вижу, это время, которое уйдёт для проверки вашей идеи. В идеале оно должно быть как можно меньше.

Однако когда вы разрабатываете какой-то SaaS в одиночку и еще вне работы, то даже разработка MVP может занять несколько месяцев, а то и год. Особенно если вы будете делать все сами на модных технологиях.

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

Я сам в какой-то момент по этой же причине перестал активно занимать сайд-проектами с целью заработка.

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

А уже с этих денег можно и спонсировать более крупные идеи. Либо же просто увеличивать доход от туда.

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

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

#devtips #work

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

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

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

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

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

#devtips #work

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

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

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

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

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

Даже если вы и напишите что-то быстрое, красивое и умное, через 2-3 месяца после вашего ухода кто-то накидает туда костылей, чтобы съэкономить себе пару часов. А через полгода-год вашего кода уже и не будет. Либо он вообще станет легаси, который никто трогать не хочет. Опять же, я может чут-чуть преувеличиваю, но обычно примерно так и происходит.

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

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

#devtips #work