От прокрастинации к продуктивности

Спасибо! Поделюсь и своим: когда задача большая и сложная, то непонятно с чего начать. Делаю так:

1. Ищу что-то похожее в интернете, в репах компании и т.д. Даже если похоже издалека, то скрестить "ужа с ежом" уже проще, чем с чистого листа

2. Из большой задачи обычно есть две проблемы:

   • Взлетит ли это

   • С чего лучше начать

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

3. И логично, конечно,  проговорить архитектуру задачи с коллегами. Из архитектуры виднее узкие места и что проверять

4. Test Driven тоже хорошо, но лично люблю 1-2 теста падающих, т.е. пишу их вместе с кодом

От джуна до тимлида и обратно: почему я выбрал код

"Никого не ждёшь, ни на кого не злишься – просто делаешь"

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

Как «взрастить» ответственность в сотруднике (реальный опыт команды)

Спасибо! По мне хотя при онбординге новичка можно точнее рассказывать внутреннее устройство команды: ожидания, взаимодействие и т.д.

То есть не ждать, что новичок сам догадается, а помочь ему влиться в команду.

Кандидат сбежал в слезах. Про накрутку опыта

Да, сделали для скорости, что умолчательные аргументы вычисляются один раз.

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

7 способов убить карьеру через GitHub

В целом соглашусь с автором. У меня лично в личном гитхабе только пакеты к nodes, python которые контрибьютил в публичное комьюнити. А так код принадлежит заказчику 😀