OP says that a masterful understanding of coding in general necessarily leads to a disregard for features that users want.
I think this is a false dichotomy -- developing a masterful understanding of what things cost must be coupled with a masterful understanding of what makes things valuable.
If OP shared what caused him to think this thought perhaps a good conversation would happen. I could see myself write something similar about CFOs after encountering one at a past startup who kept turning the air conditioning off to the point where coding in the office was a sweaty experience.
I think the title of the correct article is "You want to think like a programmer and a customer" or "You don't want to thin like a bad programmer"
If OP shared what caused him to think this thought perhaps a good conversation would happen.
Regardless of whether what is proposed is a false dichotomy, I think the post The Recovering Programmer [1] offers some explanation for what motivates the author of this blog, as does Don't Fall in Love With Your Technology [2].
The key quote from the latter would be
Slowly, not in a grand epiphany, I realized that there was something missing from the discussions in [comp.lang.forth]. There was talk of tiny Forths, of redesigning control structures, of ways of getting by with fewer features, and of course endless philosophical debates, but no one was actually doing anything with the language, at least nothing that was in line with all the excitement about the language itself.
I understand the whole series as intended to correct the reader's not caring enough about their problem domain (or, in the worst case, not having a problem domain at all). As such, it may overemphasize the importance of the problem domain to the exclusion of everything else for pedagogical reasons.
FWIW A startup I CTO is doing pretty neat things with what is, in effect, an end-user Forth. Think at the level of difficulty as creating a spreadsheet.
Overall, I agree though with your comment about the Forth community in general.
I think this is a false dichotomy -- developing a masterful understanding of what things cost must be coupled with a masterful understanding of what makes things valuable.
It might be a false dichotomy in theory ("well, no reason why these two concept should not be orthogonal") but it sure is a real dichotomy for very many developers.
People lost in the details of coding, best practices, new fancy languages, monads et al, while not producing anything of substance for real users -- or getting lost in the process and not getting anything released.
There's even a kind of term for these people "architecture astronauts" (coind by Joel Spolsky IIRC). And the even older, "worse is better" notion is also related to the same issue.
There's an even worse kind of architecture astronaut, almost the opposite of this article. It's the architects who don't even know about encapsulation, loose coupling/tight cohesion or even not to duplicate data anywhere without rules for resolving mismatches.
They've never written a line of code and yet somehow are dictating spaghetti enterprise architecture. Their business requirements are things like "must comply with all applicable standards" (isn't it your job to at least work out which ones, or are you above that?) and they never actually stop to think whether any of this will actually work.
I'll take a language hipster and a clueless business user who just wants it done any day.
I was saying much better advice to programmers is "remember to think about what makes software valuable" rather than "you don't want to think like a programmer"
I don't think that's what the OP meant at all. The claim was more along the lines of "Focusing on programming as an end in itself usually leads to an unhealthy disregard for the problem space." The key word here being "usually"; makes sense when you think about it since it's really not easy to qualify every programmer that way. The field is too vast for that.
Are you saying it is not possible to both be good at programming and have a good understanding of the business?
Of course there are compromises, but when you know both domains you make better compromises and trade-offs.
Are you saying it is not possible to both be good at programming and have a good understanding of the business?
No, I'm saying that what's merely possible doesn't matter, it's whats possible AND probable that's important.
That is, don't aspire to be THE exception that's excellent at both, first try to be adequate at both. This way, excellence at either or both, if it ever cames, won't have left you crippled at the other skill. Plus, it might never come anyway, in which case being adequate can get you a long way itself.
Also, my dichotomy (and what the original article talks about) doesn't concern merely "being good at programming", but about being preoccupied with excellence at programming -- the perfect architecture, masterful application of design patterns etc.
Most people I work with are well aware of why we write software. I can't think of anybody that is so preoccupied with the programming side of things that they disregard the business side.
So it's simply not a problem I encounter, but maybe your experience is different.
You've obviously never been in any debate involving promises vs callbacks, semicolons vs no semicolons, FP vs OO, emacs vs vim, android vs ios, R vs python, etc...
Comments
OP says that a masterful understanding of coding in general necessarily leads to a disregard for features that users want.
I think this is a false dichotomy -- developing a masterful understanding of what things cost must be coupled with a masterful understanding of what makes things valuable.
If OP shared what caused him to think this thought perhaps a good conversation would happen. I could see myself write something similar about CFOs after encountering one at a past startup who kept turning the air conditioning off to the point where coding in the office was a sweaty experience.
I think the title of the correct article is "You want to think like a programmer and a customer" or "You don't want to thin like a bad programmer"
Regardless of whether what is proposed is a false dichotomy, I think the post The Recovering Programmer [1] offers some explanation for what motivates the author of this blog, as does Don't Fall in Love With Your Technology [2].
The key quote from the latter would be
I understand the whole series as intended to correct the reader's not caring enough about their problem domain (or, in the worst case, not having a problem domain at all). As such, it may overemphasize the importance of the problem domain to the exclusion of everything else for pedagogical reasons.
[1] http://prog21.dadgum.com/56.html
[2] http://prog21.dadgum.com/128.html
FWIW A startup I CTO is doing pretty neat things with what is, in effect, an end-user Forth. Think at the level of difficulty as creating a spreadsheet.
Overall, I agree though with your comment about the Forth community in general.
It might be a false dichotomy in theory ("well, no reason why these two concept should not be orthogonal") but it sure is a real dichotomy for very many developers.
People lost in the details of coding, best practices, new fancy languages, monads et al, while not producing anything of substance for real users -- or getting lost in the process and not getting anything released.
There's even a kind of term for these people "architecture astronauts" (coind by Joel Spolsky IIRC). And the even older, "worse is better" notion is also related to the same issue.
There's an even worse kind of architecture astronaut, almost the opposite of this article. It's the architects who don't even know about encapsulation, loose coupling/tight cohesion or even not to duplicate data anywhere without rules for resolving mismatches.
They've never written a line of code and yet somehow are dictating spaghetti enterprise architecture. Their business requirements are things like "must comply with all applicable standards" (isn't it your job to at least work out which ones, or are you above that?) and they never actually stop to think whether any of this will actually work.
I'll take a language hipster and a clueless business user who just wants it done any day.
I agree it's a real problem.
I was saying much better advice to programmers is "remember to think about what makes software valuable" rather than "you don't want to think like a programmer"
I don't think that's what the OP meant at all. The claim was more along the lines of "Focusing on programming as an end in itself usually leads to an unhealthy disregard for the problem space." The key word here being "usually"; makes sense when you think about it since it's really not easy to qualify every programmer that way. The field is too vast for that.
Exactly! Why would it have to be either/or, when both is what you want.
Because humans tend to be obsessed with one or the other, humans have limited capacity, humans tend to go overboard.
At the end of the day you have to learn to make compromises, and that you can't always have "both".
Are you saying it is not possible to both be good at programming and have a good understanding of the business? Of course there are compromises, but when you know both domains you make better compromises and trade-offs.
No, I'm saying that what's merely possible doesn't matter, it's whats possible AND probable that's important.
That is, don't aspire to be THE exception that's excellent at both, first try to be adequate at both. This way, excellence at either or both, if it ever cames, won't have left you crippled at the other skill. Plus, it might never come anyway, in which case being adequate can get you a long way itself.
Also, my dichotomy (and what the original article talks about) doesn't concern merely "being good at programming", but about being preoccupied with excellence at programming -- the perfect architecture, masterful application of design patterns etc.
Most people I work with are well aware of why we write software. I can't think of anybody that is so preoccupied with the programming side of things that they disregard the business side.
So it's simply not a problem I encounter, but maybe your experience is different.
You've obviously never been in any debate involving promises vs callbacks, semicolons vs no semicolons, FP vs OO, emacs vs vim, android vs ios, R vs python, etc...