Мне кажется, что это качества любого человека, который либо стал, либо имеет потенциал стать профессионалом.
Читать дальшеАрхивы: Заметки
Немного рефлексии на тему неспособности работать в больших компаниях
Открытые и прямые коммуникации внутри зарождающегося проекта — это один из ключевых факторов выживания проекта. Тут нет еще никакого запаса прочности, все висит буквально на волоске.
Читать дальшеБанальность: главный ингредиент в разработке ПО — это люди
Управление разработкой ПО — это управление людьми. Успех разработки не в технологиях, не в инструментах, не в процессах, не в регламентах. А в людях.
Читать дальшетех ИЛИ тим лид
tech lead !== team lead
не нужно соглашаться сделать ключевой проект в короткие сроки
14 привычек высокоэффективных разработчиков
1. Пишите маленькие методы
2. Давайте содержательные имена
3. Не загромождайте ваши методы множеством параметров
4. Избегайте слишком большого количества методов в классе
5. Используя сторонние библиотеки, пользуйтесь LTS / стабильными релизами
6. Научитесь идентифицировать самые распространенные шаблоны проектирования
7. Всегда помните о разработчике, который придет вам на смену
8. Привыкайте к ударам по вашей гордости
9. Оставьте «кемпинг» более чистым, чем вы его нашли
10. Не бойтесь заниматься вещами, не связанными с написанием кода
11. Будьте фанатом документации
12. Оставляйте себе время на отдых и физическую активность
13. Учитесь отстраняться от личных чувств
14. Давайте хорошие советы
Гонка на 100 долларов с привилегированными людьми
Цитатка
«Тестирование не позволяет обнаружить такие ошибки, как создание не того приложения»
— Стив Макконелл
Исследование выявило плюсы и минусы перфекционизма
эффективность работы и перфекционизм не коррелируют между собой – перфекционисты работают не лучше и не хуже остальных.
…
общий эффект перфекционизма для сотрудников и организаций оказывается отрицательным
Может в баню этот front-end?
Зачем эта дичь вся?
Читать дальшеДублирование намного дешевле, чем неверная абстракция
Правило трех
Подумайте о математической последовательности чисел. Я называю число 2 и спрашиваю: «Какое следующее?» Возможно, это 3 или 4, но может быть и 1, и 2,1. На самом деле вы понятия не имеете. Поэтому я называю еще одно число последовательности – 4 (теперь имеем 2, 4) и спрашиваю: «Какое следующее?» Вероятно, это 6 или 8, или 16. Опять же, несмотря на нашу растущую уверенность, на самом деле мы не знаем. Я выдаю еще одно число из серии, теперь это 2, 4, 16, и спрашиваю: «Какое следующее?» Имея три точки данных, мозг программиста видит последовательность квадратов и определяет, что следующее число – 256. Это правило трех.
Данный пример и без привлечения кода показывает, что мы не должны сразу предполагать абстракцию или дизайн. С помощью отсрочки правило трех противостоит необходимости борьбы с дубликатами. Отсрочка позволяет собрать больше данных для принятия решения на их основе. Говоря словами Сэнди Мец, «дублирование намного дешевле, чем неверная абстракция».
Костыли, говно, и ебанина
Vlad Balin:
#javascript Эта картинка вызвала оживленную дискуссию в MoscowJS. Люди не понимают разницу между ебаниной, костылями, и говном. Это очень просто, я сейчас объясню.
Костыли – это в своей природе рациональная штука, она решает реальную проблему. Просто делает это кое-как, через жопу, и на скорую руку. Вот, скажем, если ваш программист с тяжелым вздохом говорит – “ладно, сейчас сговнякаем что-нибудь” – будьте уверены, он приготовился делать костыли. “Хуяк, хуяк, и в продакшн”.
А вот ебанина – это совсем другое дело. Она никакого отношения к рациональной реальности не имеет. Она берется не из нее, а целиком из мозга. Это победа интеллекта над разумом. Это, сцуко, Торжество Идеи.
Другими словами, если костыли – это недостаток ума или (чаще) времени, то ебанина – это напротив, избыток и того и другого.
С другой стороны, говно – это просто говно. Если у программиста руки растут из жопы (что в случае программиста надо понимать не буквально, а как отсутствие элементарного эстетического чувства), то независимо от наличия времени и ума не получаются ни костыли, ни ебанина. А выходит какое-то говно. Об этом явлении пишут поэты:
Олег за все берётся смело
Все превращается в говно
А если за говно берётся
То просто тратит меньше сил
Все просто, ну. Русский язык точен. Как можно эти вещи перепутать.
И я должен отметить – это самая правдивая и точная карта технологий JS из всех, что я видел.
Про программистов в белых халатах и их не взлетевшие проекты
красивые проекты не взлетают, потому что они не успевают взлететь.
Читать дальшеОбработка исключений в крупных проектах
В недрах java.security.KeyStore внезапно делят на ноль. Перехватывают это исключение и …
Читать дальшеСтатическая и динамическая типизация
ЯП с динамической и нестрогой типизацией являются самыми массовыми, потому что разработка на них удовлетворяет – бизнес. а для бизнеса одним из важных параметров является – скорость разработки.
Читать дальшеМикросервисы
А на кой они вам?
Читать дальшеФронтенд разработчик это ИЛИ программист ИЛИ верстальщик
My struggle to learn React
Читать дальшеТестируем маршрутизатор Symfony 4.1
Суть улучшений – роуты собираются в здоровенное регулярное выражение.
Таблица ниже показывает сколько времени потребовалось, чтобы найти соответствие заданным маршрутам 50.000 раз.
Колонка Diff показывает, насколько быстрее новый маршрутизатор Symfony, по сравнению с нашим нынешним (3.4).
Routes. | 3.4 | 4.1 (7d29a4d) | Diff |
---|---|---|---|
First static route | 448 ms | 382 ms | -17% |
Random static route | 1621 ms | 474 ms | -242% |
Last static route | 1826 ms | 544 ms | -234% |
First dynamic route | 746 ms | 527 ms | -41% |
Random dynamic route | 1454 ms | 531 ms | -174% |
Last dynamic route | 2039 ms | 524 ms | -289% |
Not Found | 2112 ms | 522 ms | -304% |
Как мы видим, все наши маршруты были найдены быстрее, чем раньше. Особенно заметен прирост скорости на случайном, последнем и когда маршрут не был найден.
Технический долг
Есть такое понятие: «технический долг». Когда ты создаешь и поддерживаешь программу, ты неизбежно допускаешь архитектурные просчеты.
Читать дальшеПочему я ненавижу Spring
У меня в Spring такое же отношение – вы точно уверены что в вашем конкретном проекте он нужен?
Читать дальшеНе купитесь на ERP!
Вам наобещают золотые горы.
Целый год будут трахать Ваших сотрудников.
Потом сотрудники просто смирятся с этим беспределом.
Золото превратится в грязь.
А бабки будут отжимать постоянно.