Якби мене запитали яку книгу раджу прочитати розробнику від рівня мідл і вище, це «Ідеальний код» Маконнелла. Фактично кілька книжок по різним темам зібрані разом.

Саме так, якщо компанія це в першу чергу Команда, то і компанія і працівник зацікавлені у розвитку працівника. Якщо якась із сторін починає тягнути ковдру на себе — діла не буде, рано чи пізно співробітництво закінчиться.

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

Про хинкали и есть анекдот :) Наподобие того, каким должен быть врач.

Профессор в мединституте:
— Cейчас мы с вами, товарищи студенты, пойдём в морг на практику.
В морге:
— Итак! Врач должен быть небрезгливым и внимательным!
С этими словами профессор берёт свой палец суёт в ж#пу трупу и облизывает палец. Все студенты поморщились, но повторили.
— Молодцы! Вы не брезгливые! Но врач должен быть ещё и внимательным! Совал-то я один палец, а облизывал другой
---------------------------------

Сейчас мы товарищи программисты сходим в хинкальню на практику ;) Проверим, насколько вы внимательны ;)

Так в тому то і біда. :( Дуже часто на співбесідах з’являються люди, з досвідом 3-5 років, які нічого не читають крім окремих статей, та стековерфлоу. Але кажуть: я можу вирішити будь яку задачу. Так, окрему конкретну задачу він вирішить, але коли він вирішить 50 задач, то виникне проблема. У тому що він зробив не буде загального підходу, архітектури, буде незрозумілий код, і т. д.
Я вже багато разів втикався з тим, що наприклад розробники з кваліфікацією мідл, не можуть побудувати складну систему. Вони звісно будують, але на якомусь етапі технічний борг настільки зростає, що чим далі, тим систему важче розвивати. І перемогти це може або підвищення кваліфікації, або купа грошей.

А про розвиток, я зверху відповів — це комплекс. Треба розуміти загальні підходи, методології (наприклад DDD, ООП, TDD, патерни і т.д) . Треба знати інструмент і технологію. Тобто прочитати документацію. Треба практично щось зробити, щоб використати отриманні знання. І в кінці отримати фідбек від колег, щоб зрозуміти, що ти зробив все так. Тоді ви будете розвиватись.

Мої герої: не читали, особливо нічого не створювали, не намагались комунікувати з колегами. Який може бути розвиток?

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

Навчання це комплексна справа. Треба і документацію читати, і практично щось робити і намагатися вивчити загальні речі, підходи. Наприклад системне мислення.
А один із софтскілів, це вміння і в першу чергу бажання зрозуміти іншу людину. Якщо ви майже по всім тезам не згодні, може ви чогось не зрозуміли? ;)

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

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

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

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

Я відповів вище. Ситуація просто нагадала про проблему, до якої усі звикли і намагались не звертати уваги.

Саме так, не переймайтесь, якщо чогось не знаєте, усього знати не можна. :)

Але мова в першу чергу про адекватність: людина яка не вміє будувати, не може називатись будівельником. З іншого боку, якщо батько і син адекватно себе оцінюють, але продовжують робити те, що вони роблять, то це шахраї, які обманюють людей. Тому автора поста просто «розвели». Звісно добре якщо він від цього отримав задоволення, але так буває далеко не завжди.

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

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

Эта бытовая ситуация проказывает, что человек невнимательный, некоммуникабельный и как говорится, варится в «собственном соку». Она просто напомнила о том, что и так все знали, но перестали обращать внимание.

Тоесть вы считаете, что вам должны платить, за то что вы учитесь? :))))

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

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

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

«Борітеся — поборете!» . З першого погляду продукт не простий, а це означає що самому його підняти важко. Тому критично важливо мати партнера. Бажаю успіхів у Вашій нелегкій справі.

Думаю вы не разобрались, что именно метрики показывают. И второе для чего их применять. Логическая цепочка:
— метрики дают возможность оценить сложность кода. В данном случае это совокупность показателей, каждый показывает что-то свое; Кроме того они связаны: уменьшил цикломатическую сложность — увеличил количество методов.
— чем сложнее код пишет программист, тем хуже для проекта, тем тяжелее работать с єтим кодом.
— получив набор метрик по коду написанному программистом, можно научить его писать код лучше.

И ваше высказывание "

Никакая метрика не измерит качество кода.

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

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

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