12 ms·

I assume 'talkers' means people that only talk. OP isn't making a case for or against planning, just saying that if you're taking a small team approach, once th

I assume 'talkers' means people that only talk. OP isn't making a case for or against planning, just saying that if you're taking a small team approach, once the planning is sufficient, the people who do the planning also have to jump in and produce. Your 'small team' can't be one programmer with a team of BAs, POs and designers looking over their shoulder for 40 hours a week.

lucideer 7y ago
This obviously doesn't apply across the board (but what does), but in my experience, on engineering teams I've been on, so-called & self-proclaimed "doers" are only doers of highly visible work, whereas the "talkers" are the real behind-the-scenes doers. They do the invisible maintenance work and a part of the reason they "talk" so much is because they know from experience what the burden of managing technical debt. is (and that they'll be stuck doing it) and they want to talk/plan out/advise people on the least burdensome options. They invisibly help/mentor the self-proclaimed "doers" on the projects they've eagerly taken on without any clue as to how challenging it will end up being (the same project the "talkers" cautioned others about because their knowledge gave them some degree of foresight). The truth is, you probably need both breeds. The "doers" for ambition and the ability to actually start something (without getting lost in months of talking/planning) and the "talkers" to insist on the limited amount of talking/planning needed and actually have the knowledge to follow through.
- varjag 7y ago
  There's always more people willing to tell you what to code than the people who can code. You are not mentoring anything if you can't step in and do the job yourself.
  - watwut 7y ago
    I would point out he described people who do the most uncomfortable work on the project and therefore also talk to other people. The "does" he described cherry pick easy, fun, highly visible work, refuse to coordinate with others, dont help with integrating other peoples parts and then take offense when people doing integration complain.
- username90 7y ago
  Hiring armchair architects will not do you any good, you want doers with enough experience doing things that they can plan when needed.
  - watwut 7y ago
    He did not des armchair architect: > They do the invisible maintenance work and a part of the reason they "talk" so much is because they know from experience what the burden of managing technical debt This is literally the people who deal with consequences of bad code. If you fire on bad code and then you leave maintennance on others, you are the "armchair" one. Because you are not dealing with consequences.
    - username90 7y ago
      Everyone who does maintenance work thinks they could do better than the original creators, most of the time they are wrong. They go and decide to do a rewrite by committee to ensure everything is clean now, sit in endless meetings discussing the best way to do things, end up with a product doing half the things of the old one since they make even slower progress than the pace they would go at even with massive amounts of technical debt, and because their clean solutions actually are less flexible than the old "ugly" ones. Now we have two versions of the products to maintain since we couldn't migrate everything meaning we now have more technical debt than before. The result is roughly the same as if someone just sat and churned through everything on his own, just that you now don't have a clear culprit to blame.
      - watwut 7y ago
        I like how you build strawman maintenance programmer and completely twist original debate around. Good rhetorical trick, but not much more. In practice, purely maintennace programmer is rare up to not existing. Most people do both maintennace and new projects. I have seen many people who wanted to cherry pick the best tasks, never coordinated and left after "finishing". They never even learned about issues of their decisions - because they run away as their creation was becomming hard to keep.
ashtonkem 7y ago
OP indeed does seem to be making a fairly anti-planning case. Banning anyone telling anyone else what they should be making is very anti-planning.
- username90 7y ago
  It didn't really say you shouldn't tell people what to build, but that they should build what they want. This means instead of ordering them to build something you should convince them to build it, this ensures they are fully on board with the shared vision and possibly they might even have good arguments and convince you that their version is better.
  - ashtonkem 7y ago
    I agree that in general it’s better to persuade than it is to order. But once you cross a certain organizational size, it becomes indistinguishable from just not planning at all. Once your company and product crosses a certain size, planning on persuading every single team in the critical path to care about every single product feature is a fool’s errand; a certain amount of “we need X by Y” must come in to play.

lucideer 7y ago

This obviously doesn't apply across the board (but what does), but in my experience, on engineering teams I've been on, so-called & self-proclaimed "doers" are only doers of highly visible work, whereas the "talkers" are the real behind-the-scenes doers. They do the invisible maintenance work and a part of the reason they "talk" so much is because they know from experience what the burden of managing technical debt. is (and that they'll be stuck doing it) and they want to talk/plan out/advise people on the least burdensome options. They invisibly help/mentor the self-proclaimed "doers" on the projects they've eagerly taken on without any clue as to how challenging it will end up being (the same project the "talkers" cautioned others about because their knowledge gave them some degree of foresight). The truth is, you probably need both breeds. The "doers" for ambition and the ability to actually start something (without getting lost in months of talking/planning) and the "talkers" to insist on the limited amount of talking/planning needed and actually have the knowledge to follow through.

varjag 7y ago
There's always more people willing to tell you what to code than the people who can code. You are not mentoring anything if you can't step in and do the job yourself.
- watwut 7y ago
  I would point out he described people who do the most uncomfortable work on the project and therefore also talk to other people. The "does" he described cherry pick easy, fun, highly visible work, refuse to coordinate with others, dont help with integrating other peoples parts and then take offense when people doing integration complain.
username90 7y ago
Hiring armchair architects will not do you any good, you want doers with enough experience doing things that they can plan when needed.
- watwut 7y ago
  He did not des armchair architect: > They do the invisible maintenance work and a part of the reason they "talk" so much is because they know from experience what the burden of managing technical debt This is literally the people who deal with consequences of bad code. If you fire on bad code and then you leave maintennance on others, you are the "armchair" one. Because you are not dealing with consequences.
  - username90 7y ago
    Everyone who does maintenance work thinks they could do better than the original creators, most of the time they are wrong. They go and decide to do a rewrite by committee to ensure everything is clean now, sit in endless meetings discussing the best way to do things, end up with a product doing half the things of the old one since they make even slower progress than the pace they would go at even with massive amounts of technical debt, and because their clean solutions actually are less flexible than the old "ugly" ones. Now we have two versions of the products to maintain since we couldn't migrate everything meaning we now have more technical debt than before. The result is roughly the same as if someone just sat and churned through everything on his own, just that you now don't have a clear culprit to blame.
    - watwut 7y ago
      I like how you build strawman maintenance programmer and completely twist original debate around. Good rhetorical trick, but not much more. In practice, purely maintennace programmer is rare up to not existing. Most people do both maintennace and new projects. I have seen many people who wanted to cherry pick the best tasks, never coordinated and left after "finishing". They never even learned about issues of their decisions - because they run away as their creation was becomming hard to keep.

ashtonkem 7y ago

OP indeed does seem to be making a fairly anti-planning case. Banning anyone telling anyone else what they should be making is very anti-planning.

username90 7y ago
It didn't really say you shouldn't tell people what to build, but that they should build what they want. This means instead of ordering them to build something you should convince them to build it, this ensures they are fully on board with the shared vision and possibly they might even have good arguments and convince you that their version is better.
- ashtonkem 7y ago
  I agree that in general it’s better to persuade than it is to order. But once you cross a certain organizational size, it becomes indistinguishable from just not planning at all. Once your company and product crosses a certain size, planning on persuading every single team in the critical path to care about every single product feature is a fool’s errand; a certain amount of “we need X by Y” must come in to play.