5 ms·

The programmer in this story has realised this fundamental truth: The spoken word is ephemeral and easily forgot. The design of the product that pays the bills

The programmer in this story has realised this fundamental truth: The spoken word is ephemeral and easily forgot. The design of the product that pays the bills is not so easily undone. What people say in meetings; all the posturing and preening; the petty one-upmanship and power-play — none of this has any relevance to what actually gets done in the real world. When it comes to what actually gets implemented — all of the power is in the hands of the programmer who gets there first. After all — once the die has been cast and the direction set, who is going to undo the work and start again? In this, the programmer is the decider. Programmers have an immense amount of power, and there is no reason whatsoever why he shouldn’t simply ignore the pointless social preening and get on and make the product that he wants to. After all, the consequences of his decisions will ripple far and wide thorough the product and beyond and have a heft; a level of consequence and a permanence that no ‘soft’ skills specialist can match.

locopati 9y ago
Except that the programmer rarely has an idea of the big picture and the business problems that need solving and often sees the world through narrow lenses of 'problems I've solved before' or 'how things are done' or 'knowing what's going on'. All those 'soft' skills are figuring out what needs doing (even if it's often difficult to translate that into a product that can be developed).
scandox 9y ago
> What people say in meetings; all the posturing and preening; the petty one-upmanship and power-play — none of this has any relevance to what actually gets done in the real world. That just sounds like you've had very negative experiences in terms of meetings / company culture. I have lots of meetings where collaboratively we come up with much better approaches to problems, by sharing information and ensuring everybody is aware of other people's perspectives and domain expertise. Sometimes yes there is confusion and BS. But if we push through it, we usually come out doing better work - or in the ideal case LESS work!
- w_t_payne 9y ago
  My comment illustrates the situation in a particularly dysfunctional and corrosive organisation. Whilst none of us want to work in a place like this, and none of us enjoy the experience if and when we are forced to do so; we cannot pretend that workplaces like this do not exist. Sadly, dysfunction is probably more prevalent than we would like to admit. Fortunately, we are blessed to live in a world with endless variety; a world in which workplaces with a much healthier and productive culture also exist; places which genuinely foster cooperation and loyalty and encourage and support their employees to contribute and to feel positively about their contribution.
partycoder 9y ago
A healthy team is a team with high social capital: a team that seeks the common good, where people clean up after themselves and volunteer to help others. Everyone wants the best idea to prevail. All this while preserving critical thinking and trusting other people with the feedback that is necessary to improve. Their most important competitor is another company. An unhealthy team is a team with low social capital: a team that seeks individual gain and people force others to pick up after their technical debt. Everyone wants their own idea to prevail. All this while avoiding any form of uneasy conversation and withholding feedback. Their most important competitor is each other.
- 0xFFFE 9y ago
  I couldn't agree more, once team members start focusing on personal glory they lose the big picture. From that point onwards team becomes an inefficient machine with sustained decay.
- firepoet 9y ago
  Absolutely! And I've seen companies with reward structures that focus on individual performance cause a lot of these unhealthy teams to arise unwittingly.
- AstralStorm 9y ago
  To a point. When the entire team is essentially stonewalled, not given agency or overloaded it will degrade.
- w_t_payne 9y ago
  I agree. I also think that there are far too many unhealthy teams in the world.
amelius 9y ago
> What people say in meetings; all the posturing and preening; the petty one-upmanship and power-play — none of this has any relevance to what actually gets done in the real world. So you are saying that you have never seen a solid software system that shouldn't have been built?
icebraining 9y ago
Besides scandox's comment, where do you work that you can actually do that and get away with it? Where I've worked, a programmer who did that might get to decide a few things unilaterally, but not for long.
- ndh2 9y ago
  This happens if your superior doesn't critically evaluate anybody's work, and there are no code reviews. So if there's no feedback culture. At my company, my superior sometimes writes emails regarding commits, but since he doesn't write that down (waiting-for list in GTD) I figured that I can simply ignore the emails, and nothing happens. The result is cowboy coding.
  - watwut 9y ago
    My experience with code review is that code reviewer is the one holding the power and refuses to accept code until it does what customer did not wanted. If you have position without checks, including code reviewing, it will be abused.
    - firepoet 9y ago
      This is an unfortunate experience. The best environments I've seen have a core value of respect for others, and code reviews exist to benefit not just the customer but also future programmers (which also ultimately benefits the customer but in more indirect ways, such as reducing cost of change). The absolute best are the ones where the reviewer is giving advice, but can't hold back integration. Much less threatening circumstance. More collaborative.
    - w_t_payne 9y ago
      The best reviews that I have experienced are side-by-side reviews with the author walking the reviewer through the code. The author finds most of the bugs; the role of the reviewer is to force the author to cover all the ground; asking questions where he does not understand something.
- 9y ago
watwut 9y ago
> When it comes to what actually gets implemented — all of the power is in the hands of the programmer who gets there first. After all — once the die has been cast and the direction set, who is going to undo the work and start again? In this, the programmer is the decider. That is how you loose customers. And how software teams get bad reputation and then wonder why-oh-why are other departments so hostile next time they have requirements. And why other departments assume bad intentions on honest bugs - because their experience in the past was exactly that.
- w_t_payne 9y ago
  Absolutely true ... which is why you have to work very very hard to prevent the rot from setting in in the first place. Setting the right organisational culture is such an important step in avoiding this corrosive and unhealthy situation.
albertgoeswoof 9y ago
> Programmers have an immense amount of power, and there is no reason whatsoever why he shouldn’t simply ignore the pointless social preening and get on and make the product that he wants to. what so you're just going to ignore everyone else and build something you think is right, because you're writing the code? I would most certainly undo your work and fire you, it would be much cheaper than selling all of your assumptions.
- w_t_payne 9y ago
  That is presuming you are able to find out what is happening -- the dysfunctional situation that I described comes about mainly because everybody is pedalling so hard they don't have time for humane man-management let alone watertight oversight and review. In a half-way competent organisation the team is able to align to common goals and people can be trusted to work together towards a mutually agreed outcome. It is when the organisation is run in an aggressively competitive dog-eat-dog manner -- where (for example) a five man team is responsible for its' own profit and loss; where the teams that are perceived as performing well -- that are willing to lie and deceive more aggressively -- are allowed to cannibalise budget and resources from teams that try to maintain some semblance of decency -- where your nationality and race have a bearing on whether you have credibility within the organisation -- where managers scream at each other in the corridors and conspire against each other behind their backs -- and where engineers are threatened with lawsuits should they dare to leave ...

locopati 9y ago

Except that the programmer rarely has an idea of the big picture and the business problems that need solving and often sees the world through narrow lenses of 'problems I've solved before' or 'how things are done' or 'knowing what's going on'. All those 'soft' skills are figuring out what needs doing (even if it's often difficult to translate that into a product that can be developed).

scandox 9y ago

> What people say in meetings; all the posturing and preening; the petty one-upmanship and power-play — none of this has any relevance to what actually gets done in the real world. That just sounds like you've had very negative experiences in terms of meetings / company culture. I have lots of meetings where collaboratively we come up with much better approaches to problems, by sharing information and ensuring everybody is aware of other people's perspectives and domain expertise. Sometimes yes there is confusion and BS. But if we push through it, we usually come out doing better work - or in the ideal case LESS work!

w_t_payne 9y ago
My comment illustrates the situation in a particularly dysfunctional and corrosive organisation. Whilst none of us want to work in a place like this, and none of us enjoy the experience if and when we are forced to do so; we cannot pretend that workplaces like this do not exist. Sadly, dysfunction is probably more prevalent than we would like to admit. Fortunately, we are blessed to live in a world with endless variety; a world in which workplaces with a much healthier and productive culture also exist; places which genuinely foster cooperation and loyalty and encourage and support their employees to contribute and to feel positively about their contribution.

partycoder 9y ago

A healthy team is a team with high social capital: a team that seeks the common good, where people clean up after themselves and volunteer to help others. Everyone wants the best idea to prevail. All this while preserving critical thinking and trusting other people with the feedback that is necessary to improve. Their most important competitor is another company. An unhealthy team is a team with low social capital: a team that seeks individual gain and people force others to pick up after their technical debt. Everyone wants their own idea to prevail. All this while avoiding any form of uneasy conversation and withholding feedback. Their most important competitor is each other.

0xFFFE 9y ago
I couldn't agree more, once team members start focusing on personal glory they lose the big picture. From that point onwards team becomes an inefficient machine with sustained decay.
firepoet 9y ago
Absolutely! And I've seen companies with reward structures that focus on individual performance cause a lot of these unhealthy teams to arise unwittingly.
AstralStorm 9y ago
To a point. When the entire team is essentially stonewalled, not given agency or overloaded it will degrade.
w_t_payne 9y ago
I agree. I also think that there are far too many unhealthy teams in the world.

amelius 9y ago

> What people say in meetings; all the posturing and preening; the petty one-upmanship and power-play — none of this has any relevance to what actually gets done in the real world. So you are saying that you have never seen a solid software system that shouldn't have been built?

icebraining 9y ago

Besides scandox's comment, where do you work that you can actually do that and get away with it? Where I've worked, a programmer who did that might get to decide a few things unilaterally, but not for long.

ndh2 9y ago
This happens if your superior doesn't critically evaluate anybody's work, and there are no code reviews. So if there's no feedback culture. At my company, my superior sometimes writes emails regarding commits, but since he doesn't write that down (waiting-for list in GTD) I figured that I can simply ignore the emails, and nothing happens. The result is cowboy coding.
- watwut 9y ago
  My experience with code review is that code reviewer is the one holding the power and refuses to accept code until it does what customer did not wanted. If you have position without checks, including code reviewing, it will be abused.
  - firepoet 9y ago
    This is an unfortunate experience. The best environments I've seen have a core value of respect for others, and code reviews exist to benefit not just the customer but also future programmers (which also ultimately benefits the customer but in more indirect ways, such as reducing cost of change). The absolute best are the ones where the reviewer is giving advice, but can't hold back integration. Much less threatening circumstance. More collaborative.
  - w_t_payne 9y ago
    The best reviews that I have experienced are side-by-side reviews with the author walking the reviewer through the code. The author finds most of the bugs; the role of the reviewer is to force the author to cover all the ground; asking questions where he does not understand something.
9y ago

watwut 9y ago

> When it comes to what actually gets implemented — all of the power is in the hands of the programmer who gets there first. After all — once the die has been cast and the direction set, who is going to undo the work and start again? In this, the programmer is the decider. That is how you loose customers. And how software teams get bad reputation and then wonder why-oh-why are other departments so hostile next time they have requirements. And why other departments assume bad intentions on honest bugs - because their experience in the past was exactly that.

w_t_payne 9y ago
Absolutely true ... which is why you have to work very very hard to prevent the rot from setting in in the first place. Setting the right organisational culture is such an important step in avoiding this corrosive and unhealthy situation.

albertgoeswoof 9y ago

> Programmers have an immense amount of power, and there is no reason whatsoever why he shouldn’t simply ignore the pointless social preening and get on and make the product that he wants to. what so you're just going to ignore everyone else and build something you think is right, because you're writing the code? I would most certainly undo your work and fire you, it would be much cheaper than selling all of your assumptions.

w_t_payne 9y ago
That is presuming you are able to find out what is happening -- the dysfunctional situation that I described comes about mainly because everybody is pedalling so hard they don't have time for humane man-management let alone watertight oversight and review. In a half-way competent organisation the team is able to align to common goals and people can be trusted to work together towards a mutually agreed outcome. It is when the organisation is run in an aggressively competitive dog-eat-dog manner -- where (for example) a five man team is responsible for its' own profit and loss; where the teams that are perceived as performing well -- that are willing to lie and deceive more aggressively -- are allowed to cannibalise budget and resources from teams that try to maintain some semblance of decency -- where your nationality and race have a bearing on whether you have credibility within the organisation -- where managers scream at each other in the corridors and conspire against each other behind their backs -- and where engineers are threatened with lawsuits should they dare to leave ...