Про общительность программистов

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

Мол, это замкнутые, неразговорчивые личности с признаками то ли социопатии, то ли социофобии (а может и то и другое подходит).

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

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

Например, со мной всё наоборот: люди, с которыми имел общение, всегда удивлялись: «Стёпа, ты программист? Не поверю, что ты такой активный и за компом сидишь!»

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

Конференции, митапы, доклады - вот где происходит твоё личное информационное обогащение, и именно за счёт общения.

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

На Хабре написали про набирающий обороты тихий уход

Вкратце: «делай самый минимум, лишь бы не уволили и платили оклад»

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

В этом ничего постыдного. Даже есть что-то интересное. Например, в этом подкасте с ним, можно услышать следующие тезисы (применительно к IT):

▪️В компании, чей продукт давно зарабатывает деньги можно вырабатывать самый минимум

▪️Разработчик получать больше не за то, что он делает больше, а по факту роста, который происходит сам по себе

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

Например, вы два раза middle: делаете работы по принципу «тихого ухода» не больше чем один, а получаете больше чем senior.

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

Что думаете?

#хабр

Изобретать велосипеды плохо?

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

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

Например, большая часть современной музыки состоит из заимствования, семплирования и переработки переработанного. Даже в классической музыке есть такие примеры: «Кармен» Жоржа Бизе сочинялась на основе малоизвестной кубинской авторской песни.

Вернёмся обратно в мир битов и байтов. Можно вспомнить много разных инструментов, которые решают одну и ту же задачу, а значит являются по отношению друг к другу велосипедами. Например, React PropTypes, Flow, Typenoscript - все добавляют статическую типизацию в JavaScript на этапе компиляции.

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

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

А вот что делать с устареванием документации?

Бизнес-процесс поменяли, выпилили, распилили и всё - она запутывает ещё больше.

В коммерческой разработке, на мой взгляд, самая крутая документация - это история изменений: внятные коммиты, overview [pull|merge] реквестов, fsd в confluence, комменты в jira и так далее

А jsdoc/xmldoc/комментарии круче смотрятся в личных проектах, чтобы как минимум самому не запутаться

https://news.1rj.ru/str/java_kabal/133

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

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

Использование MediatR - это одна из самых острых и горячих тем в .NET разработке.

Сам пока не пришёл к единому мнению по этому вопросу. С одной стороны инструмент даёт много возможностей, с другой приносит много проблем.

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

Бегите на Хабр, читайте и ставьте плюсы!

#хабр

abstract class vs interface

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

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

Если прислушаться к постановке вопроса интервьюером в том видео, ссылку на которое оставлена, то можно услышать подсказку: «а зачем нам и то, и другое, если это одно и тоже?»

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

Суть различия даже не в том, что в класс можно засунуть данные, а в интерфейс - нет. Это как раз сделать можно с помощью свойств или get/set методов.

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

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

C# vs Java

Как много в этом звуке для сердца энтерпрайзера слилось…

Все знают, что Java вышла и раньше, да и у её создателя большая борода. Значит она круче!

Хотя в C# была проведена большая работа над ошибками (устройство памяти, дженерики, value types), потом вообще LINQ завезли. Значит он круче!

Так в Java завезли stream API, в конце концов, может она круче? Да нет же, TPL + async/await - киллер фича C#, он вне конкуренции!!!

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

Поэтому, в последнее время популярны вопросы и публикации: «Что есть в C#, чего нет в Java?»
Я же вам скажу, что есть очень крутые вещи, которые подчинённые Гейтса ещё не успели перенести и, в некоторых случаях, очень зря.

Об этом мой новый пост на Хабре. Скорее туда - читать, ставить плюсы и повышать рейтинг!

Если кто-то до сих пор думает идти в Я

Настоятельно рекомендую посмотреть вот этот подкаст.

Рекорд Гиннесса по уходам от ответа на вопрос и переобуванию на скорость. Феноменально раздражающая личность.

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

Очень жду C# 11

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

Раньше я сам пытался ступить на поле этих открытий в своих статьях на Хабре «Абстрактная алгебра в действии» и «Властелин Структур».

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

Неожиданно, но ожидаемо

Вопреки всеобщим воплям о конце русского IT и другому подобному популярному мнению, зарплаты не падают.

А вполне даже растут. Новые условия == новые возможности. Держите руку на пульсе

Refit

Делюсь с Вами, мои дорогие подписчики, крутой находкой из мира .NET!

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

С помощью Refit можно пилить интеграции с апишками, просто объявляя интерфейсы. Весь бойлерплейт реализации Refit сгенерирует сам в рантайме. Кроме этого, там есть:

▪️Поддержка XML, JSON

▪️Гибкая настройка HttpClient

▪️Поддержка Polly

▪️Интеграция с DI и HttpClientFactory

▪️и многое многое другое

Ссылочка на GitHub проекта

Command Line Parser

Если вы пишете консольные утилиты и не знаете, как быстро и эффективно разработать API для CLI, то обязательно приглянитесь к библиотеке Command Line Parser.

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

▪️определение параметров (обязательных/необязательных, именованных, позиционных)

▪️создание команд (в том числе со своими собственными параметрами)

▪️гибкая настройка сообщения со справочной информацией и сообщения об ошибке

CommandLineParser прост в использовании, не имеет никаких сторонних зависимостей и позволяет пользоваться всей мощью ООП при проектировании параметров своего консольного приложения.

Ссылка на GitHub

System.IO.Abstractions

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

Тогда обратите внимание на пакет System.IO.Abstractions. И тогда проверка операций ввода/ввода станет проще!

Его суть довольна проста: статические методы из System.IO по типу File.WriteAllText теперь доступны через ряд специальных абстракций. Код под капотом тот же самый, только теперь он внедряемый и тестируемый.

И конечно, ссылка на GitHub

Техдолг в pet project

Последние две с лишним недели потел над pet project. Хотел выпустить киллер фичу, но, когда начал копать, просто выпал в осадок…

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

Сначала рефакторинг инфраструктуры: избавился от сторонних файлов в поставке, и разбил гигантский Main на тестируемые модули.

Потом рефакторинг доменки и вообще попытка её описания: в PR изменёнными оказались почти все файлы проекта.

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

Параллельно с этим настроил CI/CD через GitHub Actions - сижу и радуюсь жизни. А также пишу все свои мысли, замечания и выводы в issues и pull requests.

В общем, вроде проф. деформация, но с другой стороны, всё это сделано не ради того, чтобы сделать.

Опыт правильной коммерческой разработки показал, как можно писать код клёво и удобно. Я сделал выбор в пользу собственного комфорта и не прогадал.
Правда к фиче ещё даже не приступил)

Немного о pet project

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

Отвечаю.

Сейчас мой основной open source contribute - это попытка создать JavaScript без изъянов. Точнее TypeScript без изъянов.

Для описания мотивации, цели, причин и следствий нескольких абзацев telegram поста не хватит. Но, небольшой спойлер: готовлю материал об этом для новой медиа-площадки.

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

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

В общем, чтобы проникнуться кодом и поднять мне мотивацию продолжать его писать, вы можете зайти на GitHub и поставить звёздочку!

Про найм

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

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

Поделитесь в комментариях своим опытом в текущей ситуации

Кстати, рекрутёры стали гораздо реже спрашивать: «почему меняете место работы?»
и подобнее вопросы

Это прогресс! Нас услышали!

Нестандартная ситуация

История без имён и скриншотов, потому что я добрый и этичный.

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

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

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

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

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

Про беженцев

На фоне резко возросшей тенденции к релокации информационное пространство заполнилось некоторым количеством материала. На глаза попалась пара историй эмигрантов. Например, эта и вот эта.

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

Нет, вы только прочитайте формулировку: «давно созрело желание пожить в цивилизованном государстве с работающими социальными институтами»

Насколько же это субъективно и эмоционально. Видимо, вместо занятия разработкой такие «специалисты» проходят уроки в школе сарказма Тони Старка.

Тоже хотел бы посетить пару уроков, ведь потом оказывается, что:

▪️Покупательская способность зарплаты падает на несколько порядков

▪️Уровень развития b2c сервисов где-то в каменном веке

▪️Совершенно другой и непонятный ландшафт как рынка труда, так и социума

В общем, не поддавайтесь истерии новостного фона.