What would it mean to know what it means to know what sort of "game" is programming? Sometimes I think there's a competition going on in the tech blogosphere to set up the thinnest possible...
What would it mean to know what it means to know what sort of "game" is programming? Sometimes I think there's a competition going on in the tech blogosphere to set up the thinnest possible metaphors..
I don't know, i think it was quite an apt metaphor. The "game" is getting paid to program, and being successful at doing so. For most, success will come from not making mistakes in their code,...
I don't know, i think it was quite an apt metaphor. The "game" is getting paid to program, and being successful at doing so.
For most, success will come from not making mistakes in their code, rather than making brilliant code.
For code I write, for example, it's far more important to deliver quickly, work correctly, and not easily break. Those are all examples of 'avoiding mistakes.' Performing optimally, especially if it requires clever tricks that are harder to comprehend and maintain, is rarely important.
On the other hand, writing code is unlike a performance and more like writing in that you can make all the mistakes you like as long as you remove most of them. When programming, the tools will...
On the other hand, writing code is unlike a performance and more like writing in that you can make all the mistakes you like as long as you remove most of them. When programming, the tools will usually tell you what to do, or maybe your coworkers will during code review. (At least for shallow bugs.) Writing code that works the first time seems rare?
In understood it to be more about considering the mindset and motivating factors arising from it, and less the gamification aspect. And yes, a case could probably be made in the opposite...
In understood it to be more about considering the mindset and motivating factors arising from it, and less the gamification aspect.
And yes, a case could probably be made in the opposite direction, where the subsequent editing/review process is a "winner's game".
It definitely reveals a certain mindset to use that terminology. But it rings true with me. When describing to a friend my experience in getting up to speed with much more experienced programmers...
It definitely reveals a certain mindset to use that terminology. But it rings true with me. When describing to a friend my experience in getting up to speed with much more experienced programmers I said the job is mostly knowing how not to screw yourself over. What libraries do you use? The ones you know best (within reason). Which architectural decision do you go with? The one that won’t back you into a corner later when things need to change.
If you want to be a world's best in some particular field of programming, it is good to know what kind of strategy you have to follow to reach that goal. Otherwise, the metaphor is not that...
If you want to be a world's best in some particular field of programming, it is good to know what kind of strategy you have to follow to reach that goal. Otherwise, the metaphor is not that useful. My hunch is that any job is a "losers game" in a corporate environment: the only thing you have to focus on is to make less error than most of your peers. That encourages the minimization of risk-taking.
This was my take also. The title would be more accurate as "Programming in the corporate world is a losers game". Speaking more generally you have to reach quite a bit to label particular aspects...
This was my take also. The title would be more accurate as "Programming in the corporate world is a losers game".
Speaking more generally you have to reach quite a bit to label particular aspects of programming as winning and losing. In sports there is a clear goal with limited variables. Programming has a wide array of goals in different fields/contexts with an even wider variety of ways to achieve those goals.
Agreed. It's analogous to the difference in the article's example between expert players and amateur players. You can't paint tennis as a whole as either a winner's game or a loser's game because...
Agreed. It's analogous to the difference in the article's example between expert players and amateur players. You can't paint tennis as a whole as either a winner's game or a loser's game because it depends on the skill level of the players involved. Similarly, you can't paint programming as a whole as either a winner's game or a loser's game because there are many factors at play--including something as simple as the type of task you're performing, e.g. feature development vs. refactoring--so that any specific instance of programming you look at could be categorized one way or the other.
Whether it's tennis or programming, you have to decide whether it's a winner's game or a loser's games based on the current frame of reference.
The winner's game / loser's game concept is an interesting one. It's not related to programming, but I think by these definitions, chess is a loser's game at almost all levels, except for the...
The winner's game / loser's game concept is an interesting one. It's not related to programming, but I think by these definitions, chess is a loser's game at almost all levels, except for the weird skill belt where swindles and gambits dominate regular play.
Conversely, in all of my experience with martial arts, they are typically winner's games at all but the most novice of levels.
Unlike you heathens, I really like this metaphor. Once your product has the basic table stakes, it's a losers game. You lose more customers than you win when adding code, by hurting usability,...
Unlike you heathens, I really like this metaphor.
Once your product has the basic table stakes, it's a losers game. You lose more customers than you win when adding code, by hurting usability, performance, reliability, quality, forcing users to adopt the new shiny...
I think marketing is a winners game, and part of marketing is adding code, so there is always a balance there.
But branding is a losers game. Rarely are the best products the best because of some killer feature. Normally they are the best because they just.... dont... suck.
I agree with others that the metaphor is not an ideal one. That said, it's an interesting way of looking at things. I think there's a kernel of a useful idea here. If we spend all of our time...
I agree with others that the metaphor is not an ideal one. That said, it's an interesting way of looking at things. I think there's a kernel of a useful idea here. If we spend all of our time trying not to have "faults" (i.e. bugs, bad architecture, etc.), we have less time to spend on writing useful features and optimizing things.
But what's interesting to me is that these days we have an enormous number of tools at our disposal for quickly finding problems and writing code with fewer defects. Things like address sanitizers, leak detectors, thread sanitizers, static analysis, etc. For example, I can write a function, then run the static analyzer on it and know before I've even run it once whether I've caused one of a large class of bugs, including things like memory leaks.
Back in the 90s, I remember buying a tool that would sit in the background and pause you program every few seconds, scan the entire heap of your app, and tell you if you had leaks. It was a janky utility that barely worked, but it was a life saver! It could tell you if you didn't free memory, if you freed it and tried to re-use it, etc. Now those tools are no longer janky utilities — they're first class citizens built-in to the developer tools and you can set them up to run quickly and easily on every build or commit.
I guess I'm not sure how the author would consider unit tests and other automated tests that either run on each build or each commit. Are they "trying not to lose points" because they're looking for faults? Or are they "trying to win points" because they automate the task of finding regressions and you know about them before you commit a change? I don't think I care either way. They make my code better and cause me to spend less time thinking about bugs, giving me more time to think about the problem at hand.
What would it mean to know what it means to know what sort of "game" is programming? Sometimes I think there's a competition going on in the tech blogosphere to set up the thinnest possible metaphors..
I don't know, i think it was quite an apt metaphor. The "game" is getting paid to program, and being successful at doing so.
For most, success will come from not making mistakes in their code, rather than making brilliant code.
For code I write, for example, it's far more important to deliver quickly, work correctly, and not easily break. Those are all examples of 'avoiding mistakes.' Performing optimally, especially if it requires clever tricks that are harder to comprehend and maintain, is rarely important.
On the other hand, writing code is unlike a performance and more like writing in that you can make all the mistakes you like as long as you remove most of them. When programming, the tools will usually tell you what to do, or maybe your coworkers will during code review. (At least for shallow bugs.) Writing code that works the first time seems rare?
In understood it to be more about considering the mindset and motivating factors arising from it, and less the gamification aspect.
And yes, a case could probably be made in the opposite direction, where the subsequent editing/review process is a "winner's game".
It definitely reveals a certain mindset to use that terminology. But it rings true with me. When describing to a friend my experience in getting up to speed with much more experienced programmers I said the job is mostly knowing how not to screw yourself over. What libraries do you use? The ones you know best (within reason). Which architectural decision do you go with? The one that won’t back you into a corner later when things need to change.
If you want to be a world's best in some particular field of programming, it is good to know what kind of strategy you have to follow to reach that goal. Otherwise, the metaphor is not that useful. My hunch is that any job is a "losers game" in a corporate environment: the only thing you have to focus on is to make less error than most of your peers. That encourages the minimization of risk-taking.
This was my take also. The title would be more accurate as "Programming in the corporate world is a losers game".
Speaking more generally you have to reach quite a bit to label particular aspects of programming as winning and losing. In sports there is a clear goal with limited variables. Programming has a wide array of goals in different fields/contexts with an even wider variety of ways to achieve those goals.
Agreed. It's analogous to the difference in the article's example between expert players and amateur players. You can't paint tennis as a whole as either a winner's game or a loser's game because it depends on the skill level of the players involved. Similarly, you can't paint programming as a whole as either a winner's game or a loser's game because there are many factors at play--including something as simple as the type of task you're performing, e.g. feature development vs. refactoring--so that any specific instance of programming you look at could be categorized one way or the other.
Whether it's tennis or programming, you have to decide whether it's a winner's game or a loser's games based on the current frame of reference.
The winner's game / loser's game concept is an interesting one. It's not related to programming, but I think by these definitions, chess is a loser's game at almost all levels, except for the weird skill belt where swindles and gambits dominate regular play.
Conversely, in all of my experience with martial arts, they are typically winner's games at all but the most novice of levels.
Unlike you heathens, I really like this metaphor.
Once your product has the basic table stakes, it's a losers game. You lose more customers than you win when adding code, by hurting usability, performance, reliability, quality, forcing users to adopt the new shiny...
I think marketing is a winners game, and part of marketing is adding code, so there is always a balance there.
But branding is a losers game. Rarely are the best products the best because of some killer feature. Normally they are the best because they just.... dont... suck.
I agree with others that the metaphor is not an ideal one. That said, it's an interesting way of looking at things. I think there's a kernel of a useful idea here. If we spend all of our time trying not to have "faults" (i.e. bugs, bad architecture, etc.), we have less time to spend on writing useful features and optimizing things.
But what's interesting to me is that these days we have an enormous number of tools at our disposal for quickly finding problems and writing code with fewer defects. Things like address sanitizers, leak detectors, thread sanitizers, static analysis, etc. For example, I can write a function, then run the static analyzer on it and know before I've even run it once whether I've caused one of a large class of bugs, including things like memory leaks.
Back in the 90s, I remember buying a tool that would sit in the background and pause you program every few seconds, scan the entire heap of your app, and tell you if you had leaks. It was a janky utility that barely worked, but it was a life saver! It could tell you if you didn't free memory, if you freed it and tried to re-use it, etc. Now those tools are no longer janky utilities — they're first class citizens built-in to the developer tools and you can set them up to run quickly and easily on every build or commit.
I guess I'm not sure how the author would consider unit tests and other automated tests that either run on each build or each commit. Are they "trying not to lose points" because they're looking for faults? Or are they "trying to win points" because they automate the task of finding regressions and you know about them before you commit a change? I don't think I care either way. They make my code better and cause me to spend less time thinking about bugs, giving me more time to think about the problem at hand.