Секреты IT-предпринимателя

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

Для меня этот персонаж очень интересен: мне очень откликается то, что он говорит про свободу слова, приватность данных и др., но вот 2 самые важные причины👇

1. Он разработчик, и даже первые годы после основания соц. сети ВК он сам же писал в нем код, следил за серверами и тд.
2. Он один из тех, кто воплотил мечту чуть ли не любого разработчика - закОдил свой проект, который взлетел. Сначала ВК, потом ТГ.

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

А откликается это всё мне потому, что я так же увлечен своим делом не только как собственник бизнеса, но и абсолютно всем, что происходит внутри. А особенно – технической частью 🔥

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

Я их понимаю так👇

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

Ведь у него с ВК так и было: нормального выбора то у него и не было. Важно лишь то, что он сделал после этого. И этим после стал Telegram.

Или может у вас есть своя интерпретация? 🤔

Инструкция_по_установке_личного_GPT_ассистента_в_Telegram.pdf

1.7 MB

Друзья, делюсь с вами возможностью БЕСПЛАТНО использовать chatGPT 4 turbo в любых своих целях без ограничений. Причем что еще классно - в собственном телеграм-боте. Работая с chatGPT я уже себе столько процессов упростил, но об этом в другой раз.

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

По возвращению в РФ обнаружил, что мой VPN на WireGuard перестал работать с мобильной сети и работает только через WiFi. Что еще больше меня расстроило - chatGPT распознает его как VPN и не дает пользоваться, даже имя платную подписку. Забавно, что отключить ежемесячные платежи можно только в личном кабинете, но туда я не могу попасть даже с VPN 😂️️️️️️

Но потратив пару часиков сегодня вечером я нашел рабочую связку, по которой работает у меня всё и без тормозов, включая chatGPT:
- самый дешевый сервак от Digital Ocean (нужна зарубежная карта для оплаты 5$/мес) в Нидерландах
- сделать всё, что описано в этой статье https://habr.com/ru/articles/785186/ (с кое-чем пришлось повозиться)
- на айфон приложение streisand
- на мак приложение hiddify next

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

Channel name was changed to «Роман Чернов»

Про моё желание переехать в Майами

Уже второй раз я путешествую по США и сейчас мы с женой находимся в Майами - одном из самых знаменитых городов США по фильмам, да и не только.

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

Вот одна из историй, связанная с Майами:

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

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

Честно признаюсь, однажды в личном разговоре с заказчиком по имени Дейв я сказал ему, что был бы рад переехать в США, Майами и работать там в крутой компании (как их) в качестве разработчика.

Почему я ему об этом сказал?

Он занимал достаточно высокую позицию в своей компании и я надеялся, а вдруг он понял что я идеальный кадр в их компанию и предложит мне помочь с трудоустройством и релокацией в Майами?

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

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

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

Полезные статьи для разработчиков

Последний в этом году дайджест интересных статей из мира IT. Будет здорово, если тоже поделитесь чем-то интересным, что читали за последнее время.

💻 Статья для новичков на сайте Айтилогии. Насколько глубоко нужно разбираться в JavaScript для старта в разработке и какие аспекты изучать в первую очередь. В статье все разложено по полочкам.

🟣 Полезный материал для тех, кто использует среду разработки Visual Studio: объясняют, как настроить библиотеку SFML.

👍 Ценные лайфхаки для разработчиков: тимлид рассказывает о 5 принципах написания читаемого кода. Для некоторых принципов приведены примеры React и JavaScript.

👻 Последнее время то и дело слышим о киберпреступлениях — «кладут» серверы, взламывают сайты, сливают информацию, воруют страницы в соцсетях. Статья рассказывает о 5 полезных инструментах, которые помогут не стать жертвой киберпреступлений.

⚔️ А еще можно попробовать пройти тест и узнать, как хорошо вы разбираетесь в вопросах кибербезопасности: тест «Кибербезопасность в мемах».

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

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

👩‍💻 Немного интересной истории. Хватит говорить, что разработка только для мужчин, оказывается первыми программистами были женщины! И именно они её придумали.

💊 И под конец о здоровье. Врач-невролог рассказывает о туннельном синдроме у программистов и как с ним бороться. Вещь серьезная, советую заглянуть. Заодно проверите, нет ли у вас признаков этой болячки.

Люди, которые написали «Hello, World» на JavaScript и уже ждут оффер на 150 тысяч:

У кого не получится в ИТ?

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

❌ Вы идете в IT, потому что это «модно». Сейчас часто бывает, что в IT стремятся попасть люди, далёкие от понимания того, в чём заключается работа, например, программиста. Сразу платят за обучение профессии, а потом разочаровываются. Сначала лучше попробовать разные интенсивы или марафоны, написать самостоятельно код и понять, а реально ли вы хотите этим заниматься?

❌ Вы не любите учиться. Чтобы расти в профессии, нужно быть любопытным, интересоваться новинками, постоянно изучать новые технологии. Всё очень быстро развивается, нужно быть не только в теме обучения, но также очень много читать форумы, следить за ведущими компаниями-разработчиками и т. п. Будьте готовы, что обучение станет неотъемлемой частью работы. В этой сфере нельзя прочитать две книги и 20 лет работать.

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

❌ Вы боитесь самостоятельности и ответственности. Много информации необходимо искать самостоятельно, фильтровать ее, пробовать, ошибаться, рисковать. А еще принимать решения, может не сразу, но впоследствии, когда перейдете на уровень Middle — точно. И никто не будет говорить, что делать и как правильно.

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

И, конечно, без развитых мягких навыков — коммуникации, тайм-менеджмента и других, о которых часто говорю в этом канале, придется непросто. Но это во многих сферах. Что бы вы добавили к этому списку?

Куда расти разработчику?

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

Конечно, в начале карьеры мало кто будет задумываться: «А что дальше?». Но через несколько лет такие мысли подкрадываются, особенно у тех, кто не любит однообразие в работе.

Итак, куда же может развиваться программист, не меняя сферы, но меняя формат работы?

1. Развитие до Full stack. Во-первых, если хочешь расти, стоит овладевать широким кругом твердых навыков и расти до разработчика полного цикла. На это уже можно положить 5-7 лет. Да и потом постоянно учиться, потому что технологии совершенствуются постоянно.

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

2. Тим-лид. Уже став Senior Full stack, можно претендовать на должность тим лида. Этот человек принимает все ответственные решения в техническом плане на проекте, решает самые сложные участки проекта. По сути, берет на себя весь проект, и ему помогает пара дополнительных программистов

Для развития до тим лида нужно развивать мягкие навыки: работа в команде, коммуникативность, навыки руководителя и другие.

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

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

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

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

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

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

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

5. Свой стартап по разработке ПО. Про нюансы и трудности своего стартапа я уже как-то рассказывал.

6. Развитие своего продукта – коробочное решение или SaaS сервис. Вы придумываете и создаёте сервис и его продаёте, постоянно улучшая и дорабатывая.

Большой плюс такого варианта – у вас есть готовое предложение клиенту, которое довольно просто понять и оценить. Но есть и сложности: если идея на массового потребителя, то вероятно ее уже реализовали. Если идея на очень узкий рынок – на ней сложно заработать.

Классно создать что-то новаторское, что упрощает жизнь и действительно нужно пользователям.

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

👨🏻‍💻Как делать рефакторинг кода?

Как же подступиться к коду и с чего начать, если код требует доработок или обновлений? Рефакторинг — это маленькие последовательные улучшения кода. Чистить можно всё, но в первую очередь найдите эти проблемы:

🔧 Мёртвый код. Переменная, параметр, метод или класс больше не используются: требования к программе изменились, но код не почистили. Мёртвый код может встретиться и в сложной условной конструкции, где какая-то ветка никогда не исполняется из-за ошибки или изменения требований. Такие элементы или участки текста нужно удалить.

🔧 Дублирование. Один и тот же код выполняет одно и то же действие в нескольких местах программы. Вынесите эту часть в отдельную функцию.

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

🔧 Слишком длинные функции и методы. Оптимальный размер — 2-3 десятка строк. Если получается больше, разделите функцию на несколько маленьких и добавьте одну общую. Пусть маленькие выполняют по одной операции, а общая функция их вызывает.

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

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

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

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

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

А что вы чаще всего находили, что не давало вашему коду начать работать?

Anonymous Poll

47% - ;

23% - )

30% - }

Рефакторинг кода: когда ваш код пора полечить?

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

Зачем нужен рефакторинг?

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

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

✔️ сохранить архитектуру проекта, не допустить потери структурированности;
✔️ упростить жизнь будущих разработчиков, сделать код понятным и прозрачным для всех членов команды;
✔️ ускорить разработку и поиск ошибок.

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

Но иногда код сам просит срочного рефакторинга. Вот несколько признаков:

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

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

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

Хотите расскажу, как последовательно делать рефакторинг? Ставьте огоньки, и следующий раз распишу.

А вы как себя называете? 😳