How do programmers think?
July 8, 2010 7:43 PM Subscribe
What does it mean when someone says you think like a programmer?
Someone said this to me the other day and i don't really understand it because I've never programmed before.
(Also, I checked via MetaTalk whether this is chatfilter and the consensus is that it is not.)
Thanks for your insights.
Someone said this to me the other day and i don't really understand it because I've never programmed before.
(Also, I checked via MetaTalk whether this is chatfilter and the consensus is that it is not.)
Thanks for your insights.
Programming involves methodical, step-by-step thinking. If I tell someone they "think like a programmer", I mean to say that they are very good at breaking a big idea/process down into small, methodically organized chunks.
posted by gorillawarfare at 7:57 PM on July 8, 2010 [3 favorites]
posted by gorillawarfare at 7:57 PM on July 8, 2010 [3 favorites]
What you were doing when they said this?
(And can you reproduce the circumstances and see if they say it again?)
posted by RobotHero at 7:57 PM on July 8, 2010 [1 favorite]
(And can you reproduce the circumstances and see if they say it again?)
posted by RobotHero at 7:57 PM on July 8, 2010 [1 favorite]
Response by poster: I was building complex financial models in Excel.
posted by dfriedman at 7:58 PM on July 8, 2010
posted by dfriedman at 7:58 PM on July 8, 2010
Best answer: Programmers often have to start from vague general descriptions of what somebody wants, and produce machine-readable instructions that tell a computer precisely what to do. To me, "thinking like a programmer" means analyzing the general concept and finding all the unclear, vague, or ambiguous elements and asking the right questions to resolve those into clear statements of how a system or process should work.
This also gets into thinking about how various rules and procedures might conflict with each other, and figuring out or finding out how those will be resolved. It's about pursuing all those loose ends and poorly defined things until there are none, and following this down to a low enough level of detail that it can actually be implemented or built.
Plenty of non-programmers have this sort of thinking pattern. It's common in any field at the level where a person actually has to make something tangible out of a more abstract design or idea. It's the opposite of stopping the thought processes at the point where somebody says "well, that's just an implementation detail." Programmers have to figure out the implementation details!
There are various more specific ways that programmers think depending on their specific application area, programming paradigms they use, and so on, but what I described above is the thing that it seems to me is common to programmers in general. So maybe this is what the person meant.
posted by FishBike at 7:59 PM on July 8, 2010 [6 favorites]
This also gets into thinking about how various rules and procedures might conflict with each other, and figuring out or finding out how those will be resolved. It's about pursuing all those loose ends and poorly defined things until there are none, and following this down to a low enough level of detail that it can actually be implemented or built.
Plenty of non-programmers have this sort of thinking pattern. It's common in any field at the level where a person actually has to make something tangible out of a more abstract design or idea. It's the opposite of stopping the thought processes at the point where somebody says "well, that's just an implementation detail." Programmers have to figure out the implementation details!
There are various more specific ways that programmers think depending on their specific application area, programming paradigms they use, and so on, but what I described above is the thing that it seems to me is common to programmers in general. So maybe this is what the person meant.
posted by FishBike at 7:59 PM on July 8, 2010 [6 favorites]
Programmers are problem-solvers. You may be good at identifying the root cause of a problem, and devising an optimal solution for it.
posted by The Winsome Parker Lewis at 7:59 PM on July 8, 2010
posted by The Winsome Parker Lewis at 7:59 PM on July 8, 2010
Best answer: Were they a programmer? This makes a big difference.
Non-programmers have an image of what a programmer is and how they might think. As a programmer, I probably have a much different view of what it means to be a programmer.
Programming has this reputation as being very left-brained, very logical, etc. Thinking like a programmer, according to this stereotype, would be the opposite of thinking like an artist.
But actually, programming can be incredibly creative, so if they emphasis is on "thinking like a robot/logically" vs. "thinking like an artist/creatively" -- that's a false dichotomy.
If you're talking about really thinking like a programmer -- how a programmer actually thinks versus how they're perceived as thinking -- it's that you're lazy but a very special kind of lazy:
Let's say you give a non-programmer a task, and tell them that they have to perform this task 100 times. The task takes 1 minutes each time. A non-programmer will take 100 minutes doing the task 100 times, and then will be done.
A programmer, on the other hand, will think, "Well, wait a minute. How can a work this so that the task is automated?" And will, say, 20 minutes rewriting it so that the tasks are automated. Halfway through running the batch, the programmer will suddenly say, "You know what, I can actually make this apply to even more cases, just in case I'm asked to do this again, but slightly differently." So then you re-run the batch to make sure the new more generalized function works on the task set, and maybe even create a bunch of fake tasks to test the function for other edge cases. By the time the programming is completed, you might have spent 60 minutes doing programming or more. In all honesty it's not unusual to spend the same amount of time as the tasks would have taken.
But here's the thing: the next time the programmer gets the 100 tasks, they push a button and it's done in less than a minute. And they keep generalizing it so that it can keep accommodating new functionality. Then, they keep honing it. Even though it doesn't really matter, they're going to make it more efficient, reducing loops so that instead of the script taking 2.8 seconds it takes 1.6 seconds. Does the extra second matter? Not at all (at least, not under most working conditions). Yet the programmer is still going to feel the urge to "fix" it.
I can't remember the source, but I remember reading that an ideal program would be one which you could either compile as a word processor or a spreadsheet program just by changing a compiler flag.
posted by Deathalicious at 8:06 PM on July 8, 2010 [18 favorites]
Non-programmers have an image of what a programmer is and how they might think. As a programmer, I probably have a much different view of what it means to be a programmer.
Programming has this reputation as being very left-brained, very logical, etc. Thinking like a programmer, according to this stereotype, would be the opposite of thinking like an artist.
But actually, programming can be incredibly creative, so if they emphasis is on "thinking like a robot/logically" vs. "thinking like an artist/creatively" -- that's a false dichotomy.
If you're talking about really thinking like a programmer -- how a programmer actually thinks versus how they're perceived as thinking -- it's that you're lazy but a very special kind of lazy:
Let's say you give a non-programmer a task, and tell them that they have to perform this task 100 times. The task takes 1 minutes each time. A non-programmer will take 100 minutes doing the task 100 times, and then will be done.
A programmer, on the other hand, will think, "Well, wait a minute. How can a work this so that the task is automated?" And will, say, 20 minutes rewriting it so that the tasks are automated. Halfway through running the batch, the programmer will suddenly say, "You know what, I can actually make this apply to even more cases, just in case I'm asked to do this again, but slightly differently." So then you re-run the batch to make sure the new more generalized function works on the task set, and maybe even create a bunch of fake tasks to test the function for other edge cases. By the time the programming is completed, you might have spent 60 minutes doing programming or more. In all honesty it's not unusual to spend the same amount of time as the tasks would have taken.
But here's the thing: the next time the programmer gets the 100 tasks, they push a button and it's done in less than a minute. And they keep generalizing it so that it can keep accommodating new functionality. Then, they keep honing it. Even though it doesn't really matter, they're going to make it more efficient, reducing loops so that instead of the script taking 2.8 seconds it takes 1.6 seconds. Does the extra second matter? Not at all (at least, not under most working conditions). Yet the programmer is still going to feel the urge to "fix" it.
I can't remember the source, but I remember reading that an ideal program would be one which you could either compile as a word processor or a spreadsheet program just by changing a compiler flag.
posted by Deathalicious at 8:06 PM on July 8, 2010 [18 favorites]
Best answer: Building from what FishBike said:
Plenty of non-programmers have this sort of thinking pattern. It's common in any field at the level where a person actually has to make something tangible out of a more abstract design or idea.
Depending on the programming you are doing, sometimes what you are doing is transforming the "tangible" (say, an interaction between a person and a company) and abstracting it into a combination of more generalized data structures. Then of course writing the implementation. Thinking like a programmer is a leetle bit like that scene in the Matrix where Neo looks and suddenly sees the Matrix. Programmers can look at real-world interactions and see how really they're very simple clusters of data that interact in very simple and straightforward pathways.
posted by Deathalicious at 8:13 PM on July 8, 2010 [3 favorites]
Plenty of non-programmers have this sort of thinking pattern. It's common in any field at the level where a person actually has to make something tangible out of a more abstract design or idea.
Depending on the programming you are doing, sometimes what you are doing is transforming the "tangible" (say, an interaction between a person and a company) and abstracting it into a combination of more generalized data structures. Then of course writing the implementation. Thinking like a programmer is a leetle bit like that scene in the Matrix where Neo looks and suddenly sees the Matrix. Programmers can look at real-world interactions and see how really they're very simple clusters of data that interact in very simple and straightforward pathways.
posted by Deathalicious at 8:13 PM on July 8, 2010 [3 favorites]
Thinks about boundary conditions.
Thinks about algorithmic solutions. (I would rather write a program to play sudoku than play sudoku.)
May be vulnerable to thinking about algorithmic solutions to problems that are not amenable (or only partially amenable) to algorithmic solutions. (See strong AI.)
>> ... because I've never programmed before.
Do not be deceived. If you are doing anything complex in Excel and understand why you get the results you do, you are programming.
posted by Bruce H. at 8:14 PM on July 8, 2010 [1 favorite]
Thinks about algorithmic solutions. (I would rather write a program to play sudoku than play sudoku.)
May be vulnerable to thinking about algorithmic solutions to problems that are not amenable (or only partially amenable) to algorithmic solutions. (See strong AI.)
>> ... because I've never programmed before.
Do not be deceived. If you are doing anything complex in Excel and understand why you get the results you do, you are programming.
posted by Bruce H. at 8:14 PM on July 8, 2010 [1 favorite]
I was building complex financial models in Excel.
Then you ARE a programmer.
Probably the speaker was admiring the way you tackled the problem, nothing more.
posted by i_am_joe's_spleen at 8:15 PM on July 8, 2010
Then you ARE a programmer.
Probably the speaker was admiring the way you tackled the problem, nothing more.
posted by i_am_joe's_spleen at 8:15 PM on July 8, 2010
Best answer: Another characteristic: Programmers are great at finding the exceptions to every rule. This skill is important, since a disproportionately large amount of code and time go towards dealing with edge cases.
As a stupid simple example - Maybe you design a form and ask a user to enter an 8 character string. Now you have to deal with every way that the user could screw this up: Did they enter 9 characters? Did they enter 7 characters? Did they enter no characters at all? Did they enter some special character (like a semi colon) that could screw up the code if not dealt with correctly? Getting the input is one line of code; dealing with edge cases might be a hundred.
So thinking like a programmer might mean that you have a strong intuition for what types of things commonly go wrong and are good at dealing with them before they become a problem.
posted by chrisamiller at 8:16 PM on July 8, 2010 [7 favorites]
As a stupid simple example - Maybe you design a form and ask a user to enter an 8 character string. Now you have to deal with every way that the user could screw this up: Did they enter 9 characters? Did they enter 7 characters? Did they enter no characters at all? Did they enter some special character (like a semi colon) that could screw up the code if not dealt with correctly? Getting the input is one line of code; dealing with edge cases might be a hundred.
So thinking like a programmer might mean that you have a strong intuition for what types of things commonly go wrong and are good at dealing with them before they become a problem.
posted by chrisamiller at 8:16 PM on July 8, 2010 [7 favorites]
On MetaFilter, this username is a serious edge case.
Case in point: Deathalicious vs. [@I][:+:][@I].
posted by Deathalicious at 9:16 PM on July 8, 2010
Case in point: Deathalicious vs. [@I][:+:][@I].
posted by Deathalicious at 9:16 PM on July 8, 2010
I remember someone saying that, if you needed a set of instructions for standing up, walking to the door and opening it, a good programmer would start with concepts like "What are you? Human? OK, now where are you?"
posted by Cool Papa Bell at 9:23 PM on July 8, 2010 [3 favorites]
posted by Cool Papa Bell at 9:23 PM on July 8, 2010 [3 favorites]
how a programmer actually thinks versus how they're perceived as thinking -- it's that you're lazy but a very special kind of lazy:
I use this explanation all the time to explain what programming is.
posted by Bonzai at 9:34 PM on July 8, 2010
I use this explanation all the time to explain what programming is.
posted by Bonzai at 9:34 PM on July 8, 2010
Essentially, you can't misspell programmer without grammar.
posted by Cold Lurkey at 9:40 PM on July 8, 2010
posted by Cold Lurkey at 9:40 PM on July 8, 2010
Not applicable in your context, but "thinking like a programmer" can be used as a derogatory term, typically applied by UI designers. Symptoms of "thinking like a programmer" include:
- Overly flexible interfaces that expose every single possible configuration option, overwhelming users
- Extensible interfaces that solves no specific problem well but has an extensibility hook so that somebody else can try and do a good job (hint: this is bad design)
- Chatty interfaces that are always telling the users about problems/asking for manual correction
- Vague and incomprehensible error messages examples
posted by crazycanuck at 9:45 PM on July 8, 2010 [1 favorite]
- Overly flexible interfaces that expose every single possible configuration option, overwhelming users
- Extensible interfaces that solves no specific problem well but has an extensibility hook so that somebody else can try and do a good job (hint: this is bad design)
- Chatty interfaces that are always telling the users about problems/asking for manual correction
- Vague and incomprehensible error messages examples
posted by crazycanuck at 9:45 PM on July 8, 2010 [1 favorite]
I'd judge this to most likely mean that you're analytical, but it could mean anything.
Did you know that searching for "recursion" on Google generates the suggestion: "Did you mean: recursion"? This programmer thinks that's funny.
posted by empyrean at 10:45 PM on July 8, 2010 [3 favorites]
Did you know that searching for "recursion" on Google generates the suggestion: "Did you mean: recursion"? This programmer thinks that's funny.
posted by empyrean at 10:45 PM on July 8, 2010 [3 favorites]
I am a programmer. Programmers are (stereotypically) in the habit of thinking literally, since we're used to talking to computers, and computers are 100% literal.
However, I think of this as kind of a negative stereotype. I rarely say things like this, and when I do, it's sort of in a teasing/affectionate way.
I would be suspicious of a non-programmer saying it.
I agree with Afro (that it depends on who it's coming from). I'm also a programmer. If I were to tell you that "you think like a programmer", I'd be saying you're smurt like me. But, if one of my coworkers (not programmers) were to tell you that "you think like a programmer", they'd probably really mean that you're an arrogant know-it-all bastard like me. Completely different meanings! :)
posted by Anthony84 at 1:20 AM on July 9, 2010
However, I think of this as kind of a negative stereotype. I rarely say things like this, and when I do, it's sort of in a teasing/affectionate way.
I would be suspicious of a non-programmer saying it.
I agree with Afro (that it depends on who it's coming from). I'm also a programmer. If I were to tell you that "you think like a programmer", I'd be saying you're smurt like me. But, if one of my coworkers (not programmers) were to tell you that "you think like a programmer", they'd probably really mean that you're an arrogant know-it-all bastard like me. Completely different meanings! :)
posted by Anthony84 at 1:20 AM on July 9, 2010
In my experience, that's a euphemism for "dear god, you are boring".
posted by orthogonality at 2:32 AM on July 9, 2010
posted by orthogonality at 2:32 AM on July 9, 2010
<foxworthy>If someone asks you "cash or credit?" and you answer "yes" then you may be a programmer.</foxworthy>
posted by plinth at 5:34 AM on July 9, 2010 [2 favorites]
posted by plinth at 5:34 AM on July 9, 2010 [2 favorites]
You have been complimented by that person.
Of course, I am a programmer. So, programmers are good, eh?
posted by Drasher at 6:18 AM on July 9, 2010
Of course, I am a programmer. So, programmers are good, eh?
posted by Drasher at 6:18 AM on July 9, 2010
I find this is a good opportunity to post one of my favorite quotes from Frederick P. Brooks and The Mythical Man Month.
"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures."
posted by mcarthey at 6:19 AM on July 9, 2010
"The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures."
posted by mcarthey at 6:19 AM on July 9, 2010
"I no longer equate thinking I'm right about something with actually being right about it.
It's now very easy for me to entertain the thought that I may be wrong even when I feel pretty strongly that I'm right. Even if I've been quite forceful about something I believe, I'm able to back down very quickly in the face of contradicting evidence. I have no embarrassment about admitting that I was wrong about something.
That all came from decades of working in a discipline that mercilessly proves you to be mistaken a dozen times a day, but that also requires you to believe you're right if you're going to make any progress at all.
...coming up with a solution is easy, it's not until there is solid evidence, demonstrating the solution in the face of attempts to disprove it, that it's of any value. I see this convergence as a sign that programming is finally becoming enough of a science that blind faith is beginning to be seen for the nonsensical position that it is.
... The practice of open-mindedness that I'm talking about is orthogonal to understanding the universe through controlled repetition. There are people to whom the experience of feeling wrong, and the action of openly admitting error, are unpleasant, even intolerable. Remaining open to that experience, even embracing it, is a practice that is more spiritual than scientific."
posted by grumblebee at 6:59 AM on July 9, 2010 [2 favorites]
It's now very easy for me to entertain the thought that I may be wrong even when I feel pretty strongly that I'm right. Even if I've been quite forceful about something I believe, I'm able to back down very quickly in the face of contradicting evidence. I have no embarrassment about admitting that I was wrong about something.
That all came from decades of working in a discipline that mercilessly proves you to be mistaken a dozen times a day, but that also requires you to believe you're right if you're going to make any progress at all.
...coming up with a solution is easy, it's not until there is solid evidence, demonstrating the solution in the face of attempts to disprove it, that it's of any value. I see this convergence as a sign that programming is finally becoming enough of a science that blind faith is beginning to be seen for the nonsensical position that it is.
... The practice of open-mindedness that I'm talking about is orthogonal to understanding the universe through controlled repetition. There are people to whom the experience of feeling wrong, and the action of openly admitting error, are unpleasant, even intolerable. Remaining open to that experience, even embracing it, is a practice that is more spiritual than scientific."
posted by grumblebee at 6:59 AM on July 9, 2010 [2 favorites]
So, lots of people here have mentioned the analytical qualities of programers.
Another trait that I consider to be programer thinking, is the ability to be very focused and single minded. I think it's been described as "hack mode", I call it "bling-blonging" after Kevin from Mission Hill (first minute). More or less you're able to block out other distractions and work, possibly non-stop for long stretches of time. Anti-social behavior, and energy drink consumption may or may not be consummate with bling-blonging. The ability to come out of bling-blonging or hack mode can have an impact on your personal life, as many spouses of programers can attest to.
Interestingly enough, as Deathalicious was saying, I think this particular mode of thinking is also seen in artist/creatives.
posted by fontophilic at 8:00 AM on July 9, 2010
Another trait that I consider to be programer thinking, is the ability to be very focused and single minded. I think it's been described as "hack mode", I call it "bling-blonging" after Kevin from Mission Hill (first minute). More or less you're able to block out other distractions and work, possibly non-stop for long stretches of time. Anti-social behavior, and energy drink consumption may or may not be consummate with bling-blonging. The ability to come out of bling-blonging or hack mode can have an impact on your personal life, as many spouses of programers can attest to.
Interestingly enough, as Deathalicious was saying, I think this particular mode of thinking is also seen in artist/creatives.
posted by fontophilic at 8:00 AM on July 9, 2010
I usually use it as short hand for "attention to detail". That doesn't just mean edge cases, but also, for example, being able to simplify a long algebraic equation without messing up your signs (this is rare, or so my students keep insisting)...
posted by anaelith at 11:39 AM on July 9, 2010
posted by anaelith at 11:39 AM on July 9, 2010
I usually use it as short hand for "attention to detail". That doesn't just mean edge cases, but also, for example, being able to simplify a long algebraic equation without messing up your signs (this is rare, or so my students keep insisting)...I don't think that's a very good thing to say. Programmers mess up syntax and make little mistakes like that all the time. Back in the day, you would usually get tons of little errors you had to fix when you first compiled a program, and it would kind of be a waste of time to worry about little details on your first draft.
But nowadays modern IDEs will check for errors as you type -- Which would be equivalent to simplifying an algebraic equation with a calculator. Which is probably how a programmer would do it. Even if they had to write the calculator first :)
posted by delmoi at 4:44 PM on July 10, 2010
I usually use it as short hand for "attention to detail".
I don't think that's a very good thing to say. Programmers mess up syntax and make little mistakes like that all the time.
Attention to detail needn't mean "not making mistakes." It can mean CARING about detail. And I think it's true that programmers tend to care deeply about details. The job kind of forces you to, even if you didn't to begin with (or -- chicken and egg -- maybe the sorts of people who are detail-obsessed are more likely to become programmers).
I write books and program computers. I'm detail-oriented in both professions. When I talk to other writers, I get really obsessive about tiny word choices. "I like that sentence, but I think 'also' throws the rhythm off. Could you use 'too' instead?" That stuff matters deeply to me, but the thing is, it's probably not going to make a difference as to whether or not the book is published.
But screw up the tiniest, tiniest detail in a program and it might not compile. Or it might compile but lead to some domino-effect chain of logic errors that are a nightmare to debug later. The act of programming TEACHES you to pay attention to detail.
There are also aspects of programming that aren't about compilation, but that many programmers get obsessive about. I'm that way (and I know I'm not alone) about identifiers (e.g. variable names).
I'll name a variable background, and then think, "It doesn't really refer to the entire background -- just the background's color." So I'll change it to backgroundColor. Then, I'll add a stroke (a frame) around the background which has a different color, so I'll rename the variable backgroundFillColor.
Maybe the system I'm working with accepts rgb colors and hsv colors, and I'll worry the variable name isn't clear enough, so I'll change it to backgroundFillRGBColor.
Then I decide to get rid of the stroke, so I'll change it to backgroundRGBColor...
This habit has bled over into real life. I wasn't like this before I became a programmer, but now I'm obsessive about file names, labels I put on file-cabinets, etc. If I head a friend say, "I like how Frankenstein had those bolts in his neck," it's hard not to say, "You mean Frankenstein's MONSTER." (I don't do this, because I'm not an asshole. But the the temptation to dot every i is there.)
posted by grumblebee at 6:48 PM on July 10, 2010 [2 favorites]
I don't think that's a very good thing to say. Programmers mess up syntax and make little mistakes like that all the time.
Attention to detail needn't mean "not making mistakes." It can mean CARING about detail. And I think it's true that programmers tend to care deeply about details. The job kind of forces you to, even if you didn't to begin with (or -- chicken and egg -- maybe the sorts of people who are detail-obsessed are more likely to become programmers).
I write books and program computers. I'm detail-oriented in both professions. When I talk to other writers, I get really obsessive about tiny word choices. "I like that sentence, but I think 'also' throws the rhythm off. Could you use 'too' instead?" That stuff matters deeply to me, but the thing is, it's probably not going to make a difference as to whether or not the book is published.
But screw up the tiniest, tiniest detail in a program and it might not compile. Or it might compile but lead to some domino-effect chain of logic errors that are a nightmare to debug later. The act of programming TEACHES you to pay attention to detail.
There are also aspects of programming that aren't about compilation, but that many programmers get obsessive about. I'm that way (and I know I'm not alone) about identifiers (e.g. variable names).
I'll name a variable background, and then think, "It doesn't really refer to the entire background -- just the background's color." So I'll change it to backgroundColor. Then, I'll add a stroke (a frame) around the background which has a different color, so I'll rename the variable backgroundFillColor.
Maybe the system I'm working with accepts rgb colors and hsv colors, and I'll worry the variable name isn't clear enough, so I'll change it to backgroundFillRGBColor.
Then I decide to get rid of the stroke, so I'll change it to backgroundRGBColor...
This habit has bled over into real life. I wasn't like this before I became a programmer, but now I'm obsessive about file names, labels I put on file-cabinets, etc. If I head a friend say, "I like how Frankenstein had those bolts in his neck," it's hard not to say, "You mean Frankenstein's MONSTER." (I don't do this, because I'm not an asshole. But the the temptation to dot every i is there.)
posted by grumblebee at 6:48 PM on July 10, 2010 [2 favorites]
Does it mean you ask the internet for what someone meant instead of the commenter themselves?
I'm a programmer, and I could use that phrase both ways (you're a good program solver vs. you don't consider how non-programmers really think). Or in your case, you could have been great at figuring out the problem in excel, or you could have built it too complex to even be usable.
My first statement is making me lean towards the latter ;)
posted by jsmith77 at 1:14 PM on July 11, 2010
I'm a programmer, and I could use that phrase both ways (you're a good program solver vs. you don't consider how non-programmers really think). Or in your case, you could have been great at figuring out the problem in excel, or you could have built it too complex to even be usable.
My first statement is making me lean towards the latter ;)
posted by jsmith77 at 1:14 PM on July 11, 2010
I sometimes get this at home because I *do* think like a programmer. Usually when I'm trying to solve a problem when someone else is trying to just vent about the problem, and I'm supposed to shut up and listen instead of trying to solve it. More recently I make some mental effort to try and divine which kind of problem I'm listening to, but with varying success.
posted by genghis at 9:01 PM on July 13, 2010
posted by genghis at 9:01 PM on July 13, 2010
This thread is closed to new comments.
2) Your thoughts are either one way or another, but never in between.
posted by Sonic_Molson at 7:57 PM on July 8, 2010