ИТ наизнанку. Посторонним В!

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

1 лайк

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

какую версию посоветуете?

В бумаге у меня такая вот (2017)


В цифре 10го года, не могу сказать что найду в них 5 отличий, читаю чаще всего цифровую копию, из бумажной делаю скриншоты на кодревью. Книга очень «насыщенная» информацией так что даже худший вариант (если он есть) будет мегаценный.

2 лайка

Немного юмора в тему:

Маркетолог спрашивает программиста: в чём сложность поддержки большого проекта?

Программист: ну представь, что ты писатель и поддерживаешь проект “Война и мир”.
У тебя ТЗ — написать главу как Наташа Ростова гуляла под дождём по парку.
Ты пишешь “шёл дождь”, сохраняешь, вылетает сообщение об ошибке “Наташа Ростова умерла, продолжение невозможно”. Почему умерла?
Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу.
Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб.
Получаем сообщение “Поручик Ржевский умер.” Выясняется, что он в следующей главе облокачивается о столб, которого уже нет…"

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

15 лайков

8 лайков

Мой совет как программиста с 15+ летним опытом. Не учитесь по таким книжкам типа “учебникам” лучше купите, (скачайте) справочник по языку (освойте инструменты) и пишите программы своей головой. Выработаете нестандартное мышление. И понимание почему так а не эдак. Ну это если вы хотите стать настоящим программистом-творцом, а не оператором фреймворков. И рабом шаблонов. ))

2 лайка

Хорошо вам работать в изоляции, в одиночку над проектом. Большинству программистов так не повезло, приходится работать в команде, а там бывают попадаются люди с «нестандартными» решениями, которые они и сами не в состоянии осознать уже через неделю после мержа в девелоп. Тогда команде (архитектору, тим лиду, синьорам в крайнем случае) приходится рассказывать таким выдающимся личностям о стандартах разработки, общепринятых концепциях, шаблонном коде, почему отрицание плохо и тд. В такие моменты очень помогает эта и подобные книги - в них доходчивым путем описаны возможные варианты и плюсы и минусы каждой медали - бери и выбирай какой стул, так сказать, ближе.
Любой джун может написать код который не поймет ни один синьор, но только очень хороший разраб может написать код, который поймет любой джун.

3 лайка

Design и code review помогают.

1 лайк

Напомнило: how we write/review code in big tech companies - YouTube

2 лайка

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

1 лайк

Как долго?

Ну вот вчера один хороший синьор ревьюил одного хорошего джуна целый день. Задача для джуна была чуть более сложная чем стоило бы, но иначе джун не продвинется.
Сегодня другой хороший синьор ревьел хорошего мидла 2 часа. И я уже не говорю про здоровенные ПРы с кучами изменений.

Какая-то нездоровая фигня.

3 лайка

Энтерпрайз

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

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

Ну это очень комплексная вещь. Вообще за стандарт берут пол года на адаптацию к проекту. Тоесть типа пол года разрабу нужно что бы просто вникнуть во все процессы, познакомится с нужными людьми, запомнить архитектуру, какой модуль за что отвечает. Кто то справляется быстрее. Дальше хорошому джуну надо еще пол года что бы он мог начать выполнять мидловые задачи. Еще годик мидловых задач и джун может претендовать на позицию мидла. Тоесть где то от полутора до 2 лет синьору надо быть бадди и активно помогать около года в сумме. Многое конечно зависит от самого человека, часто видел как люди проходят этот путь быстрее, но были случаи когда сильно и затягивалось. Однажды работал с человеком у которого было 10 лет опыта по трудовой но писал он на уровне джуна.

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

1 лайк

Чаво? :wink:

«Осваивают смежные профессии» :grin:

2 лайка