4 ms·

It would seem to be very hard to get people to do the dirty work that nobody wants. (There's always a reason not to document...)

semiel 13y ago
This is an interesting take on that problem: http://michaelochurch.wordpress.com/2012/09/03/tech-companies-open-allocation-is-your-only-real-option/ http://michaelochurch.wordpress.com/2012/09/03/tech-companie...
- mathattack 13y ago
  Interesting article for much more than just that problem. So pay up for the dirty work? That seems in line with what I believe. Internal markets are good for companies. There's a bit of a question of "Where do you draw the line between being a manager just coordinating freelancers, versus actually having a company?" Perhaps it's the time horizon of employees?
yk 13y ago
Assuming that you have a well working team, then everybody will notice who 'takes one for the team' from time to time.
matwood 13y ago
The only work I consider 'dirty' work is work that doesn't help the final product. User documentation, support documentation, test plans, etc... all help the final product. I actually enjoy doing them as part of the process and as a break from heads down coding. The only work that I genuinely consider dirty work is useless work. Things like status reports or faux process fall into the useless category.
- mathattack 13y ago
  You may be the exception. I have yet to see a software shop where the documentation and test cases were all current. You never know when status reporting can help... If done right. If 20 teams who each impact the final deadline all are 90% of the time on time, you'll still likely have a late project because that 10% adds up. And in most companies that 90% is lower. It helps to have quantifiable progress metrics to understand where the trouble lies. This might not be the type of status you're referring too though.
205guy 13y ago
Or why not toss a tech writer in the arena (or a QA person if you want tests, or etc.)? Why should it be a homogeneous team of programmers?

semiel 13y ago

This is an interesting take on that problem: http://michaelochurch.wordpress.com/2012/09/03/tech-companies-open-allocation-is-your-only-real-option/ http://michaelochurch.wordpress.com/2012/09/03/tech-companie...

mathattack 13y ago
Interesting article for much more than just that problem. So pay up for the dirty work? That seems in line with what I believe. Internal markets are good for companies. There's a bit of a question of "Where do you draw the line between being a manager just coordinating freelancers, versus actually having a company?" Perhaps it's the time horizon of employees?

yk 13y ago

Assuming that you have a well working team, then everybody will notice who 'takes one for the team' from time to time.

matwood 13y ago

The only work I consider 'dirty' work is work that doesn't help the final product. User documentation, support documentation, test plans, etc... all help the final product. I actually enjoy doing them as part of the process and as a break from heads down coding. The only work that I genuinely consider dirty work is useless work. Things like status reports or faux process fall into the useless category.

mathattack 13y ago
You may be the exception. I have yet to see a software shop where the documentation and test cases were all current. You never know when status reporting can help... If done right. If 20 teams who each impact the final deadline all are 90% of the time on time, you'll still likely have a late project because that 10% adds up. And in most companies that 90% is lower. It helps to have quantifiable progress metrics to understand where the trouble lies. This might not be the type of status you're referring too though.

205guy 13y ago

Or why not toss a tech writer in the arena (or a QA person if you want tests, or etc.)? Why should it be a homogeneous team of programmers?