Дресс код, компания зарабатывает деньги не на программном продукте, …
Читать дальшеWiki Category: Дао
Хотите стать разработчиком? 10 признаков того, что вам не стоит идти в профессию ни при каких условиях
Отсутствие любознательности
Отсутствие автономности и находчивости
Отсутствие настойчивости в решении проблемы
Отсутствие радости при преодолении трудностей
Нетерпение в обучении
Ощущение скуки или усталости от мыслей
Неспособность к самостоятельному мышлению
Узкое, ригидное и хаотичное мышление
Желание получить «правильный» ответ, когда есть «хорошие» и «плохие» ответы
Неумение обращать внимание на детали
Стажёр Вася и его истории об идемпотентности API
Никогда не доверяйте ничему приходящему в вашу систему
Читать дальшеПро разработку програм и продуктов
Я тут может очевидное кому-то скажу, а кому-то может неочевидное.
Часто бывают программеры, которые типа “на проекте был бардак – ни четких ТЗ, ни куда гребем непонятно”. Это от непонимания, что никто никогда не знает зачем ПО вообще делают, и куда дорога вывезет. За редкими исключениями.
Давайте от противного. Вот есть, условно, MS Word. Туда никаких фичей, кроме текущих – и не надо. Да и тех что есть – можно выкосить половину. Можно ли сделать точно также? Да, думаю где-то за 100M баксов – вполне. Что копейки по сравнению с продажами. Можно ли достать 100 лямов, переписать Word – и зарабатывать как MS? Неа. Потому что срать будет всем на ваш новый Word. Чтобы стать продуктом, Office-у пришлось прожить с людьми десятилетия, делать фичи типа “радужный 3D-текст Comic Sans-ом с тенью” – потому что тогда это было модно. А потом – поддерживать эти фичи. Учить поколения людей форматировать пробелами. И так, не мытьем, но катаньем, они захватили рынок.
Сложность и сила ПО – не в текущем его наборе фич, а в возможности его постоянно менять. А талант программиста – не в том чтобы по спеке сделать с тестами. Он про то, чтобы предсказать куда дует ветер, и про вычленить те кусочки, которые скорее всего пригодятся – когда надо будет разобрать и собрать всё заново. Или понять что хер угадаешь куда вывезет, и просто писать код быстро, просто и без ошибок. А как поменялось – стирать и переписывать.
Сам код – вообще имеет отрицательную ценность – чем его больше, тем хуже, если ценность продукта постоянна.
не использовать технологию ради технологии, для красоты
безоговорочное доверие авторитетам, этот «аристократичный» синдром, наравне с «культом карго» — это одна из ключевых проблем современного IT.
Читать дальшеТехнический долг на проекте
Ответ кроется в самом понятии проекта. Одним из ключевых отличий проекта от других видов деятельности является уникальность конечного продукта. Там где уникальность, там и непредсказуемость, и именно она порождает изменения на проекте и вносит трудности в первоначальное проектирование системы.
Читать дальше65 вещей, которые я не знал, когда начинал программировать (а жаль)
58. Мастерство приходит с практикой
Повторение — мать учения, а один из самых надежных способов овладеть чем-то — настойчиво это практиковать.
Разрабы работают медленно и дорого — и люди считают нас лентяями. Просто в разработке всё сложно
С программным обеспечением всегда так. На поверхности кажется, что мы делаем простые штуки. Но на самом деле — оно невероятно сложное. Проблема в том, что сложность станет видна, только когда ты погрузишься во все технические нюансы.
Читать дальшеНикто не умеет управлять программистами — и все придумывают костыли, вместо решений
Есть компании, где процесс разработки реально работает отлично. Я скажу вам почему — они выиграли в лотерею. У них оказалось намного больше людей, которые хотят работать — с такими, как не управляй, все будет идти хорошо. Даже манагерскую мишуру с бордами они используют для дела, а их перформанс и по джировым, и по интуитивным метрикам ясно виден. И когда их менеджеры-не-разрабы приходят мешать им, у них за спиной стоит шикарный продукт, который даёт им право посылать эти говорящие головы к черту.
…
Но такая команда — фантастическая удача. А обычно происходит вот что. На десять человек у тебя два, которые хотят работать. Один из них тимлид, а второй увольняется.
Не давать обещаний сходу
Вывод простой — никогда не давать обещаний сразу, когда их просят.
Читать дальшеХорошие программисты пишут код, лучшие — тикеты
хорошие программисты пишут код, но лучшие пишут тикеты. Код написать проще, чем хороший тикет — это хорошее объяснение, почему этот код нужно сделать. Поэтому если вы хотите развиваться и поднимать свой уровень, то фокусируйтесь на способности объяснить другому программисту, что нужно сделать, и умению выслушать клиента или заказчика и перевести его мысли в тикеты.
Читать дальшеКак закаляется сталь
И, вот, ты остался один. Тебе не с кем посоветоваться по проблемам, которые тебе волнуют. Нет, конечно, ты можешь о чём-то поговорить с другими одиночками, они даже попробуют тебе чем-то помочь, но по факту – ты один на один с твоей областью проблем.
Читать дальше20 вещей, которые я вынес за 20 лет в программировании
– Не боритесь с инструментами — библиотеками, языками, платформами — чем бы то ни было. Старайтесь использовать присущие им конструкции
– Вы пишите код не для машин.
– Технический долг как фастфуд: допустим в умеренных количествах, но если войдёт в привычку, не успеете оглянуться, как он убьёт продукт, и это будет больно.
– Хороший код не требует документации, но отличный код задокументирован по определению.
– Никогда не начинайте кодить (разрабатывать какое-то решение), полностью не вникнув в суть задачи.
Программирование — не тяжелый физический труд, но все равно отстой
Вы полностью компетентны, и все хорошо, и вдруг все ломается.
«Шо за нах?» — восклицаете вы и начинаете отлавливать проблему. Выясняется, что однажды один идиот решил, что раз другой идиот решил, что 1/0 равно бесконечности, он может использовать это как условное обозначение для «бесконечности» для упрощения своего кода. Затем не-идиот справедливо решил, что это идиотизм, то, что должен был решить первый идиот, но поскольку он этого не сделал, не-идиот решил стать козлом и сделать это ошибкой компиляции. Затем он решил никому не говорить, что это ошибка, потому что он козел, и теперь все ваши снежинки — моча, а вы даже не можете найти кошку.
Читать дальшеТимлид – это сержант
Тимлид как сержант в американской армии. Он спит в казарме с рядовыми, умеет делать почти все лучше них, и занимается помимо этого оперативным руководством.
Читать дальшеТимлидство
Тимлид – это менеджер. На программирование времени не будет.
Читать дальшеНемного рефлексии на тему неспособности работать в больших компаниях
Открытые и прямые коммуникации внутри зарождающегося проекта — это один из ключевых факторов выживания проекта. Тут нет еще никакого запаса прочности, все висит буквально на волоске.
Читать дальшеБанальность: главный ингредиент в разработке ПО — это люди
Управление разработкой ПО — это управление людьми. Успех разработки не в технологиях, не в инструментах, не в процессах, не в регламентах. А в людях.
Читать дальшеКак стать хорошим разработчиком
Аналитическое мышление
Умение видеть картину крупным планом
Бизнес-ориентированный подход к разработке
samdark: Про проектирование и архитектуру
markdown проще рендерить единообразно, удобней хранить и делать diff.
Хороший монолит не хуже микросервисов. Плохие микросервисы с нечёткими границами гораздо хуже монолита.
Кешируйте только когда оптимизации перестали помогать.
Большинство на первый взгляд странных решений в доставшемся вам legacy-проекте там не просто так.