3 ms·
Ugh. I hate posts like this. Refactoring, speed improvements, documentation, testing, etc arent roles. They arent buckets. They arent seats you fill. Theyre par
by thinkingkong 6y ago
Ugh. I hate posts like this. Refactoring, speed improvements, documentation, testing, etc arent roles. They arent buckets. They arent seats you fill. Theyre part of every engineers job. The issue is we keep dividing issues into “product work” and “unproductive” work. If this person is fascinated with refactoring thats amazing. If theyre obsessed with speed, equally so. But there needs to be constraints on when to start optimizing and when to stop. The when to stop part is the one where people fail the most. Simultaneously, we should all be dedicating time on a regular basis to these types of activities. Like min 25% of our weeks for most companies. Instead we hide these improvements in features and complain when coworkers are “slow”.
- bradstewart 6y agoI don't think the author is suggesting you go out and hire a "refactor person", a "new feature person", a "documentation person", etc. Rather, assigning the body of required work to each developer based on her interests. If you have one new feature ticket and one refactoring ticket, don't give the new feature ticket to the developer known for refactoring too often. > But there needs to be constraints on when to start optimizing and when to stop. Now that is very true. But feels like a separate issue to me.
- thinkingkong 6y agoActually I think assigning work specifically to people ends up solidifying responsibilities. Its like the person who doesnt mind writing tests. Guess who ends up writing nothing but tests? Guess how many tests the rest of the team writes?
- Rapzid 6y agoGuess how much that person likes getting assigned to write tests after 6 months to years?