6 ms·

Let's try to see this in another perspective. Say you are now the leader/boss/manager/client and you are working with a programmer. So you receive a work and

Let's try to see this in another perspective. Say you are now the leader/boss/manager/client and you are working with a programmer. So you receive a work and from past experiences you see it's lacking documentation of architectural design choices, you see many data processing procedures done synchronously with the APIs serving layer, the coding style is different than the agreed in the organizations. So you as for polishing. And every time you ask for polishing this particular Dev cites a whole bunch of nonsense about powerplay and that the way it's done is different than his working style. You try to educate, and show why you are asking what you are asking to no avail. What follows next is a slow but sure separation of this Dev. The employee starts receiving less and less work that requires those kinds of things, only maintenance jobs. What the Dev did was effectively argue himself into isolation.

dlahoda 4y ago
so when first powerplay lost, looser starts second one to isolate dev (so therewould be reason to fire?)
- II2II 4y ago
  No. The argument is the argument over polishing work is not a power play. Work is expected to meet certain standards. A request to polish the work is an opportunity to ensure the work meets those standards, prior to cutting them loose for falling short of expectations. I have worked with many students who have felt that submitting the minimum possible should reflect the standards. The argument goes it has demonstrated they know their stuff. Sometimes they have learned the material. (Usually they haven't, but that is a separate issue.) What they are neglecting is the expectation to communicate they have learned the material in a clear manner to other people. Something similar can be said of software development. It is relatively easy to write code that solves a problem. It is more difficult to write code that solves a problem well. It is also more difficult to document the code in a manner that other people will understand, which is important since other people will will have to work on it in the future. (Even if, as the saying goes, that other person is future-you.)
arthurofbabylon 4y ago
Interestingly, I am often in the position of leader/boss/manager/client. One of my favorite questions to ask specialists is: "of everything that's in our scope, is there anything you think is not worth doing?" Another working paradigm I find critical to effective management is limiting myself to a tiny "nitpick budget" so that we focus on what matters without eroding morale/trust/time/attention (if the job is not being done to core standards, I'd find a new specialist altogether). Once again, the distinction between good work and polished work is critical. (It deserves its own essay!) And I agree with you – the ability to make this distinction – and to never push against against core standards – is a basic requirement.
- gchamonlive 4y ago
  It would be nice to have an ontological essay laying out what exactly these concepts relate to in practice. It is a subject full of nuance that I would love to read deeper into.
brudgers 4y ago
lacking documentation of architectural design choices, you see many data processing procedures done synchronously with the APIs serving layer, the coding style is different than the agreed in the organizations. If these matter, these are failures to meet requirements. Meeting requirements is not polish, it is the bar for good enough. To the degree they don't matter, asking for them is a power play.
- gchamonlive 4y ago
  Yes, the thing is that the concepts of polish and requirements are not stable across different perspectives. What I am calling requirements were viewed as unnecessary flourishes by someone else. The comment is actually motivated from experiences in my work. There was always this constant resistance from a colleague to do what I thought was a basic requirement, where he thought was unnecessary. So it is much more a matter of culture, the constructed meaning of those concepts and how they translate in practice that shape the discussion. It is a matter of quality and how different people have different perspectives on the matter, none of them being objectively wrong, because how on earth can you even be objective about it? There is nothing in essence that says that a project with well documented design principles is better than another, otherwise you would just say "it is better because it is", when in reality "it's better just because I say so and the team agrees".
  - brudgers 4y ago
    To the degree they are requirements, the work can be reassigned within the team and it will make no difference. Not fulfilling requirements is a straight up HR performance matter. An unwillingness to execute in conformance with culture is also an HR matter for cultural fit. In both cases it is not a matter of good-enough. It is a matter of not-good-enough. Situations where it is not these are what the article covers, e.g. when the important thing is someone performing as requested not as expertise indicates or when there are non-trivial opportunity costs to fulfilling the request.

dlahoda 4y ago

so when first powerplay lost, looser starts second one to isolate dev (so therewould be reason to fire?)

II2II 4y ago
No. The argument is the argument over polishing work is not a power play. Work is expected to meet certain standards. A request to polish the work is an opportunity to ensure the work meets those standards, prior to cutting them loose for falling short of expectations. I have worked with many students who have felt that submitting the minimum possible should reflect the standards. The argument goes it has demonstrated they know their stuff. Sometimes they have learned the material. (Usually they haven't, but that is a separate issue.) What they are neglecting is the expectation to communicate they have learned the material in a clear manner to other people. Something similar can be said of software development. It is relatively easy to write code that solves a problem. It is more difficult to write code that solves a problem well. It is also more difficult to document the code in a manner that other people will understand, which is important since other people will will have to work on it in the future. (Even if, as the saying goes, that other person is future-you.)

arthurofbabylon 4y ago

Interestingly, I am often in the position of leader/boss/manager/client. One of my favorite questions to ask specialists is: "of everything that's in our scope, is there anything you think is not worth doing?" Another working paradigm I find critical to effective management is limiting myself to a tiny "nitpick budget" so that we focus on what matters without eroding morale/trust/time/attention (if the job is not being done to core standards, I'd find a new specialist altogether). Once again, the distinction between good work and polished work is critical. (It deserves its own essay!) And I agree with you – the ability to make this distinction – and to never push against against core standards – is a basic requirement.

gchamonlive 4y ago
It would be nice to have an ontological essay laying out what exactly these concepts relate to in practice. It is a subject full of nuance that I would love to read deeper into.

brudgers 4y ago

lacking documentation of architectural design choices, you see many data processing procedures done synchronously with the APIs serving layer, the coding style is different than the agreed in the organizations. If these matter, these are failures to meet requirements. Meeting requirements is not polish, it is the bar for good enough. To the degree they don't matter, asking for them is a power play.

gchamonlive 4y ago
Yes, the thing is that the concepts of polish and requirements are not stable across different perspectives. What I am calling requirements were viewed as unnecessary flourishes by someone else. The comment is actually motivated from experiences in my work. There was always this constant resistance from a colleague to do what I thought was a basic requirement, where he thought was unnecessary. So it is much more a matter of culture, the constructed meaning of those concepts and how they translate in practice that shape the discussion. It is a matter of quality and how different people have different perspectives on the matter, none of them being objectively wrong, because how on earth can you even be objective about it? There is nothing in essence that says that a project with well documented design principles is better than another, otherwise you would just say "it is better because it is", when in reality "it's better just because I say so and the team agrees".
- brudgers 4y ago
  To the degree they are requirements, the work can be reassigned within the team and it will make no difference. Not fulfilling requirements is a straight up HR performance matter. An unwillingness to execute in conformance with culture is also an HR matter for cultural fit. In both cases it is not a matter of good-enough. It is a matter of not-good-enough. Situations where it is not these are what the article covers, e.g. when the important thing is someone performing as requested not as expertise indicates or when there are non-trivial opportunity costs to fulfilling the request.