Ask HN: Do you use programming tricks in real life too? | Hacker News Reader

Ask HN: Do you use programming tricks in real life too?

87 pointsjacquesm86 comments

I suddenly realized that I'm practicing 'programming tricks' in real life all the time.

Specifically, the divide and conquer strategy for problem solving and building larger things out of smaller sub assemblies, but the more I think about the more I see that plenty of the stuff that I do on a day-to-day basis has it's roots in programming (or at least that's where I picked it up).

For instance, assume nothing, trust but verify, be strict in what you send but forgiving in what you receive and so on.

Those all have real-life equivalents for me.

Professional deformation or useful trait? Do you have it too ? In what way ?

View on HN

Rather, you're using problem solving tricks in real life. If anything, programming often gives a good vocabulary for problem solving* , especially if you're not a mathematician, but it's not exactly the same. Programming works similar mental muscles, but can also encumber problems with meaningless details.

(Also, be wary of "be strict in what you send but forgiving in what you receive", it gets you web "standards". :) )

* No small thing, see e.g. Iverson's "Notation as a tool of thought". Having a good vocabulary for a problem is a great aid to brainstorming. The most recent wave of people discovering this have been buzzing about "DSLs". Before that, "little languages". Before that, I don't know.

You frequently see reference to "an algebra" or "a calculus" of something or the other :)

I used to work as sysadmin in a research institute. the language difference between researchers who program, vs your typical coder in a software shop was interesting. the researchers were in the habit of referring to "a code". to a programmer, its either "code" or "a piece of code", but never "a code". that would be like saying "a software". when I hear "a code", I think of "an error correcting code".

Yes, that usage ("a code", meaning a program) is actually quite old in the numerical modelling community -- I heard it in the early 1970s, and I think it's older than that.

I do this, and I'm pretty glad to see I'm not the only one.

Applying query tuning techniques to my daily commute saves me about 10 minutes of driving each day. I recently realized that freeway lanes have similar performance characteristics as database tables do - the more transactional the lane, the more likely it's going to have a backlog. So, instead of driving in the fast lane, the one immediately to the right of it is usually faster. My guess is that this happens because of people swerving in and out of the HOV lane illegally in an attempt to save a few minutes or whatever. Avoiding the furthest 2 right lanes is important when you can as well as people tend to merge twice immediately after entering the freeway (this is on I-10 in Phoenix, which is between 4 and 7 lanes across each way, depending on what part of town you're in).

Knowing which lanes contain forced merges allows for planning ahead as well, since you know that you're going to have to deal with double the traffic in a rate-constricted channel.

Knowing which lanes contain forced merges allows for planning ahead as well, since you know that you're going to have to deal with double the traffic in a rate-constricted channel

That sounds a lot like query caching!

There cannot be more lane changes into and/or out of the left most lane than the 2nd to left most lane (assuming no left exits) because all lane changes go through it. Furthermore it is fairly easy to get a sense of the best lane by just paying attention.

In the UK people in the 'fast' lane (over taking on the inside is illegal here). Will generally leave less space between cars, so that lane is more likely to suffer from a cascade of over-breaking causing a jam.

Yes there can be, because people who hop in and out of the HOV lane don't traverse all lanes every time they do it.

For example, Alice gets on the freeway and merges 4 times (after the initial merge) to get to the "fast lane". For ease of explanation, the lanes will be referred to like this:

  | HOV | 5 | 4 | 3 | 2 | 1 | Onramp |

(So lane #5 is the fast lane in this example)

Traffic starts slowing down, so she merges from lane 5 to the HOV lane in order to pass a few cars. She's in this lane illegally so she doesn't remain in this lane. After a few passing a few cars, she merges back into lane 5. She repeats this 3 more times before she gets off the freeway.

So, in this limited example, this is the "transaction count" of Alice's lane changes:

  Onramp <-> Lane 1 : 2
  Lane 1 <-> Lane 2 : 2
  Lane 2 <-> Lane 3 : 2
  Lane 3 <-> Lane 4 : 2
  Lane 4 <-> Lane 5 : 2
  Lane 5 <-> HOV : 8

The problem isn't people just getting over to the fast lane, staying in it and leaving, the problem is the number of transactions that the HOV <-> Fast lane pairing have due to it being relatively empty even during crowded freeway conditions.

Similarly, lanes 1 and 2 have higher transactions due to people getting on the freeway for a mile or two and exiting shortly thereafter. This may be limited to AZ freeways since the exits tend to be regularly spaced about a mile apart. The other problem is that there are quite a few people who will merge on to lane 1 going 45MPH, which causes many drivers to pass them in Lane 2.

Chronic lane changers seem to use all lanes roughly equally, so their habits mostly cancel out.

Another thing that may be different depending on where you live is that AZ allows entry and exit from the HOV lane at any time. It's not like CA where there are specific entries and exits to the HOV lanes.

Let me know if this still doesn't make sense.

This still does not make sense

  Onramp <-> Lane 1 : 2
  Lane 1 <-> Lane 2 : 2
  Lane 2 <-> Lane 3 : 2
  Lane 3 <-> Lane 4 : 2
  Lane 4 <-> Lane 5 : 2
  Lane 5 <-> HOV : 8

So the total transactions for lane 5 is 10 and HOV is 8. This is not a counterexample to what I stated.

By "fast lane", I believe icey is refering to lane 5, not HOV. He is saying lane 4 is better than lane 5 because of all the people switching between land five and HOV. He's not saying that lane 5 is better than HOV.

Thanks

I use a rough binary search from time to time. For example, if I'm looking for something in a collection of named documents I know are filed, but don't what the starting and ending documents are. This comes up from time to time.

I also use heuristics I've learned debugging - just about when to challenge assumptions, and detecting when part of my mind is trying to stick to assumptions it shouldn't. Difficult to explain precisely - sort of a 'self delusion alarm bell'.

I've also learned something about structuring debate and discussion, from programming - I sometimes keep a mental model of the discussion under progress as a stack - tangents result in a push, and I've sort of learned to 'pop' afterwards to go back to the part of discussion I'd otherwise forget.

Not sure this is so much programming tricks as a set of heuristics and mental faculties that have been trained or enhanced by programming...

I use the Birthday Paradox when I'm searching for matching socks in the morning -- rather than pick a sock and look for one that matches it, I accumulate socks and choose the first pair that match.

That's an excellent metaphor!

My other favorite programming metaphor is about skiplists: they're like a set of subway lines, with some extra express lines that skip a random (and increasing, for each level) number of stops.

I use Lisp for that same purpose whenever I do my laundry. I cons my socks ahead of time, then serialize the pairs to a drawer. O(1) lookup FTW!

Quite possibly the geekiest hn comment I've read :)

I use the futon in my bedroom as an L1 cache for frequently worn clothes.

I wrote this thing "on the complexity of sock-matching" a few years back: http://www.mail-archive.com/kragen-tol@canonical.org/msg0008...

It was more about the problem of matching socks when I put them away, but the same principle applies.

instead of casting other types, just make everything a string: buy a whole lot of pairs of the same type of sock so you don't have to worry about matching types!

I have found that communicating with people in extremely precise ways improves the speed at which they can comprehend and respond properly.

Here's an example:

Problem: When you visit McDonald's they won't supply you with any ketchup unless you ask for it. So after they give you your food, you ask "I'd like some ketchup with that". And then they give you 2 packets of ketchup. That's obviously not enough, so you have to ask again "Can I have a few more ketchup packs please". This can go on a few times until I have the actual amount of ketchup I require.

Solution: As soon as they give your food say "Give me 8 ketchup packs, please".

Bam! Problem solved.

Eating in McDonalds is like using TXT files to mimic a database. No matter how much ketchup you throw at it, it will make you sick and sorry.

McDonalds has never made me sick. Just sayin'.

Interestingly, I often experience a somewhat opposite effect.

A lot of interactions with clerks are template-based, i.e., they follow the exact same flow every time. In case of McDonald's, the standard interaction for buying a burger may go roughly like this:

    Customer: A big mac, please.
    Clerk: Would you like some french fries with that?
    Customer: No, thank you.
    Clerk: Would you like a soft drink with your burger?
    Customer: No, thank you.
    Clerk: For here or to go?
    Customer: To go, please.

However, I found that I can't shortcut this conversation even if I give all the required information right at the beginning, which annoys me quite a bit. The interaction would then go something like this:

    Customer: A big mac, please, no french fries or drink, to go.
    Clerk: Would you like some french fries with that?
    Customer: *sigh* - No, thank you.
    Clerk: Would you like a soft drink with your burger?
    Customer: No, thank you.
    Clerk: For here or to go?
    Customer: To go, please.

Too bad, the clerk process insists on reading all information from stdin instead of using the provided command line parameters.

It's because they are obliged to ask these questions anyway, because someone has an idea that it'd maximize the sales.

It's a protocol, just like TCP/IP. Your extraneous information in the header was just discarded. :-)

I've seen people use exceptions for flow control: rather than constantly checking if it's OK to keep doing something, just keeping doing it until there's a problem, handle it, then gracefully stop.

That's something I do all the time in real life.

similar here. this pattern reminds me also of "better to ask forgiveness than permission" in order to maximize productivity. Just Do It. alter/correct/stop later if/as needed.

That's an idea that I explicitly learned from computing, coming from a mathematical background where that pattern doesn't really have an analogue. I really never thought that way until I conceived of it as an adult and immediately connected it to some code I had written recently. The closest pattern of thinking I had prior to that was the idea of the scientific method, which isn't exactly the same and isn't nearly as applicable to problems in daily life.

Are you kidding? I use the scientific method quite consciously all the time. Form a hypothesis, try to come up with some relevant experiments, perform them, notice that they (usually) disconfirm the hypothesis, repeat until the hypothesis is not disconfirmed.

ooh, my wife hates that. I typically fix our cars myself when they break. When something starts making noise that I can't diagnose, I do everything I can to make it worse hoping it'll help me figure out the problem. Apparently, that's counter-intuitive.

My wife is far more analytical about most tasks than I am - I drive her crazy by not really being able to explain how I can fix most things, using a process she describes as "fiddling randomly until it works".

Your mechanic might hate that too. One difference between software and hardware is that you can't just revert the checkin that cracked your cylinder head when you were over-revving the engine to see if you could make the ping louder.

How about the idea that the best range specification is: position of first item in the range, position of first item just past the end of the range.

Programming examples: Python range function & slice notation, C++ STL ranges.

Real life example: A room is being renovated. It is unavailable starting on the 3rd, and available again starting on the 8th (as opposed to unavailable from the 3rd to the 7th -- how many days is that?).

Minimizing context-switches and exploiting caching sure helps get housework done a lot faster and with less hassle (be it doing the dishes, sweeping the floor, doing laundry, or tidying up the place). Also sort-then-process (which can be n log n if processing is linear) is usually a lot faster than sort-as-you-go (which can easily go to n²).

This is exactly why I think programming should be taught in elementary school. Programmers think about problems very differently.

How can a given problem be solved reliably using a strictly defined process? Many kids don't seem to appreciate this question. Indeed, some seem to think that problems at school or in live are obscure riddles that can be solved using talent, luck or intuition (of course they believe they lack all of those). A programmer understands that there must be a way to describe the solution to a problem in such a way that anyone (even a computer!) can figure out the solution.

Conclusion: Teach programming in school, as early as possible.

1) I use non-blocking I/O all the time :

- I don't like to answer phone calls because I'm generally busy, I'd rather listen to my voicemail and call back people later.

- I don't wait for things to finish (eg. TV ad break) by staring at them, I do something else until they are done.

2) I also treat my life as a task queue :

- I will analyze what needs to be done and tackle each problem individually (GTD-like).

3) I have an object-oriented worldview :

- I'm careful to always pass in the right arguments to people's "methods".

- My very own existence is defined by a multiple iheritance from my mom and dad classes.

4) Finally, I tend to RTFM a bit too much before taking action IRL.

premature optimization: rather than order and sort bills and receipts into separate folders, i just toss them into a big pile. why waste time on the INSERT when you SELECT from it so rarely?

Agreed -- my filing system became so much easier when I realized that reads were rare. Just bucket (well, box) by a suitable parameter, typically date, and you're done.

Of course. I think Cesar picked up "divide and conquer" from his experience with COBOL.

I wonder what would have happened if Caesar had had access to modern problem solving tools.

After all, if he could come up with something that directly leads to recursion what would he have done on the algorithm front given a mechanism more suited to the development of more complex algorithms? Regular language only gets you so far in that respect.

Absolutely. I find myself all the time typifying relationships - that is, classifying relationships in an object-oriented-typesystem-influenced way. Since computers tend to be very literal this leads itself to prejudices that are often funny when you take them far enough.

For instance, an Engineer "is a" Person who "has a" Job. They tend to be statically and early bound to their properties and functions, and if they need to change jobs, they have to be recompiled, which is expensive. If you ask them to do something that they don't know how to do, they will probably try, though may fail spectacularly segfault style, taking the whole program down. Engineers are written in C++.

A graphic designer is a Person who may or may not have a Job, or may intermittently have something that fulfills the function of a Job without being a Job itself. They tend to be dynamically late bound to their properties and functions (just ask my wife, who does a lot of freelance and contract work). They are written in Ruby.

An Entrepreneur is a Person who may or may not have any number of properties or functions at any one time, and may or may not delegate work to some other party. They are written in Javascript.

Engineers tend to have very well defined ideas of what is public and private, whereas designers wear their heart more on their sleeve. Entrepreneurs may have a public interface, but they tend to be so outgoing as to not have private data - they may have public knowledge that is simply inaccessible and out of scope.

It might not be the most correct train of thought, but it is amusing, so long as you don't take it too seriously.

Reverse engineering problem spaces in physical reality works just as well as it does in digital reality, case in point;

A few years ago I had a friend that was just about to learn the hard way that backing up their files was essential and what the click of death really meant, but this particular episode resulted in her collapsing onto the couch in her home and sobbing quietly.

Call me a softy but I can't deal well with people I care about in such a state so instead of the usual "That'll teach you, next time you ought to backup regularly" I suggested taking her drive to a data recovery specialist, however this was off the table due to cost concerns apparently and timeliness of data required from said device. This does of course exacerbate the original error of not keeping that data backed up, but I still felt the need to help her out.

So, I sat there and I thought about it for a very long time, reverse engineering the process of exactly what happens during a head crash on a hard disk platter, the head collides with the spinning platter causing physical damage to it and/or getting jammed on it and unable to reset.

Opening the drive and physically realigning the components required tools and an environment that I did not have access to, I did not have the spare parts to implement a platter switch out on a spare of the same model drive, and no clean room environment to do the job at any rate, so I thought if this were a simulation of reality and I could just magic it back like in software, how might I do that and got the image of lifting the head off the platter to reset it without opening the drive casing.

Thinking about it a bit longer made me come up with the crazy idea that the disk was constructed of metal, and metal contracts when cooled. Possibly this could result in the head being lifted off the platter for long enough for the disk spin up to realign the head if it was booted quickly after being cooled dramatically, but condensation would destroy the electronics on the drive and this would need to be accounted for.

It's kind of a crazy idea anyway and if the data is really critical and it could've been sent to a recovery specialist I would've recommended that but on hearing my idea she immediately begged me to do it. Apparently she had no idea what I was actually proposing beyond it involves the freezer and the disk or why it might work, but afterward she told me that I had that same cautiously optimistic vocal tone I get when I'm on the edge of a solved problem when we're working together and that was enough to convince her it was a surefire winner.

So, multiple freezer bags wrapping the drive and four hours later with said freezer on lowest temperature it was capable of, I quickly removed the drive, cut a hole in the outer bag that had not been covering the power and data connections, and put it into the system, spin up, no clicks. Rapidly booted into linux live CD and copied all the files off the drive, it kept running not only for the three hours necessary to do this, but apparently runs to this very day also (this was about three years ago).

She does however backup religiously now, and doesn't store anything critical on that drive anymore, and this incident was the genesis of a new dropbox customer. ;)

That's a good story, but it's about problem solving (informed by physics), not programming as such. Still cool, though.

I suppose it came to mind because to me it felt exactly like debugging.

Definitely. I'd bet a lot of good mechanics would have the knack for debugging, too, if they learned the programming stuff. (The bike shop mechanics I've known certainly have the mindset.)

Problem solving is more general than programming, that's all. I'm all for sharing good problem-solving strategies, but focusing on programming is a bit narrow. (I get a lot of inspiration from House and Berton Roueché's writing, personally, but I'm a medical history / epidemiology geek.)

Oh man, yeah. Debugging skills are totally real-life. Back when my son had an allergy/kidney problem (which he still has, but his labs have been normal twice now, fingers crossed) I always had the feeling I was debugging my child.

I don't buy that you came up with this well known hack on your own. Thanks for sharing this lie with us.

And why not? That's the whole idea behind patents on stuff that does not require years of research being nonsense.

I've come up with plenty of stuff off the cuff like the GP writes, sometimes it works, plenty of times it doesn't. I only brag about the times it worked ;)

And rightly so. Sports guys talk about various glory moments where pure luck or doing the wrong thing (according to the fundamentals) worked out well. Fishing stories are all... yeah..

Basically all groups have their lore. Everyone knows it contains an element of bragging, a lot of BS and some downright fabrication. It's not about fact reporting, its about bonding, it's about highlighting certain aspects to demonstrate traits valued in the group, it's about passing on a generalized knowledge. Hell, some places "shooting the shit" is called "telling lies with the boys".

I've done this multiple times and never once had anyone flinch at the idea... its just WHAT YOU DO when your hard drive is messed up as one of the steps.

If you don't know this, you shouldn't be on hacker news.

If this was really your idea first, thanks. I have used this technique to recover data. I didn't bag the drive though. I got the data off, and the disk lasted about 20 minutes before dying forever.

I don't like the phrase "trust but verify". I believe it gives the wrong idea of how to handle people you depend on to accomplish things.

"Delegate completely, verify periodically - and slowly build up trust when good results are repeatedly shown" is more like it.

Not holding grudges and not worrying about things that I can not change often seem like mental garbage collection techniques to me.

I tend to "regression test" things. eg. after I clean the toaster, I plug it back in and pop it down to make sure it still works.

I do follow try-catch or/and interrupt driven philosphy in my life. Do ya work assuming there is a catch-block to handle anything that might go wrong and dont think too much in the try-block, thats how i make everyday decisions. Also, dont poll on results, let them interrupt you while you are being more productive!! :)

I write software, but I consider myself, in a way, a professional scientist. I use the scientific method every day. I'm sure I work differently than pure researchers, but the gist of it is the same. Assume nothing, trust-but-verify means I make sure to have controls to compare my experiments against, and I repeat observations that others tell me they made. I form hypotheses and discard the ones that don't agree with observations until I find the one that explains the problem. Further testing and I've got a theory. Then I implement a solution. I'm much better at solving problems than I used to be, and that's a skill that's not limited to writing software. Unfortunately, I don't really do much else. If I had a life, I'm confident I would use my improved problem solving skills to solve real life problems.

Yes, I do. For example, I use all the tips mentioned on this page:

http://news.ycombinator.com/item?id=1695794

I would say that those tricks you mentioned are real life skills I use in development.

I've seen DJs use a kind of binary search to beatmatch tracks:

If the track they're bringing in is too slow, they speed it up a few percent.

When it starts getting ahead of the track they then slow it down a few percent.

When that setting then causes the track to be too slow they speed it up a little (but not back to the starting speed).

This process is repeated until the tracks are beatmatched, with smaller and smaller changes being made each time.

Each time you make an adjustment and listen to the effect you eliminate another range of the pitch slider and so improve accuracy and time taken to synchronise the tracks.

This is very useful if you have a cheap turntable or happen to use CDJs.

I've started going to the gym to work on fitness, and for weights I find sets of 16 reps far better than 15 reps (the generic starting number for the sort of work I'm doing)

For really light loads I just count to 16. If slightly heavier I count to 8 twice. 8 lifts isn't so unreasonable, right? When pushing heavier amounts I recurse again and do 2 sets of 2 sets 4. Listing something heavy four times is no big deal. If I feel like I should break into 2 sets of 2 set of 2 sets or 2 I know I'm using more load than I should be for 16 reps.

Physicaly these are all identical to a set of 16, but mentally very different.

I'm currently binary searching to find the changelist that broke my project.

So what's taking so long?

I think the searching thread is blocked waiting for the cooperative HN-browsing thread to return control.

This reminds me of a book on the work of Jean Piaget. Basically he tried to teach children to learn by teaching them programming.

Because programming provides you with the patterns of building up in chunks, testing each section independently.

If you look at alot of the revolutions in sports teaching it has come from breaking down movements via slow-mo replay and then being able to teach / debug those movements.

I would suspect that all programmers use the mental patterns from programming when faced with other tasks, but I'd be surprised if they would realize, I certainly don't.

I read a book by Focault in which he said similar things about the evolution of efficiency in the military. There was a correlation between the number of precise movements of the armies and its efficacy. This was before modern wars.

I often do branch prediction when chatting on IM's, especially with people who type slowly. For example, I ask "How did your exam went?", and before getting the answer, I type (without sending) "Sorry to hear that, but hey, you'll have another chance next week." In general, I just quickly think about possible answers, select the most probable one and type in my response without waiting. Then I get answer from the other person, and most likely send my text immediately.

Most of the time, branch prediction works great and it's a big chat optimization. If it fails, it is often of because the other person answered in a way, that my prepared sentence won't fit grammatically (I just edit it), or asked for clarification (I then CTRL+X my response for later reuse and write some clarification instead).

I think I've realized it when I started to extensively use Skype chat, which (as opposed to - for example - IRC) shows that a person is typing. When I'm asked a question and then I see that the other person is typing something, I wait with my answer, expecting a clarification or follow-up statement from the person I talk to. I guess others do that too, so I consciously avoid branch-prediction typing on Skype in order to actually get any answer from the other person.

I like to try different sorting algorithms when sorting physical things. I tried patience sorting last time I had to sort a big pile of books (I was sorting by width).

Quicksorting a deck of cards is not actually that quick, oddly.

I do this all the time. A couple of interesting ones came up while volunteering recently.

Assembly line style processes are just like shell pipes. I get data, process it, another step.

The same project I also got to act as an accumulation buffer. As things were produced I collected sets of 10 at a time of them and gave those to someone else who counted and stored them. He didn't have to walk as much and they were easier to count.

Reductio ad absurdum: http://www.iep.utm.edu/reductio . I use this with everything. Programming, math, thinking of relationships between people....

The technique comes naturally, I presume, from dealing with abstract problems. So a lot of people use it without knowing the latin logical phrase.

So a couple of examples come to mind:

1. I worked at a bar in college where I was a grill man. There was a CS student I worked with, and he was my assistant (setting up plates for food, telling me what toppings the next n burgers got, and so on) or sometimes we switched jobs. It turns out that scheduling algorithms, queueing theory, parallelism and exception handling all map very well to the grill domain. Not metaphorically either, we literally would implement various algorithms from classes and apply them to our grilling. Led to some amusing scenes, particularly when the other kitchen workers tried to listen in on our arguments. By the end of that job, we had optimized the crap out of the kitchen by applying basic algorithms.

2. I garden... a lot. I frequently do tasks the way I would program them to be done - e.g. when to plant seed(s|lings). Turns out that all at once is a terrible way to do things. Instead a garden should be "pipelined" north -> south. Some seeds this week at the north end. Some more next week just south of that. Repeat till the end of the rows. This makes the a tallest plants at the north where they don't get shaded by more southernly plants. Also, it lengthens the "season", as the north plants can be done fruiting just as the south ones are flowering. Other techniques include A/B testing, layout algorithms and other optimisation problems around compost and mulch.

More generally, I don't even realize how natural modularizing/componentizing/factoring has become to me. I have an ex-girlfriend who I would frequently fight with over this -- well the effects of it. She would bring up a problem, and I would rattle off an on-the-fly algorithm of, what needs to be done, what order, and how the tasks should be divided, with some assumed dependency resolution. To me, this was a simple starting point, I fully expected to revise and refactor, based on missed dependencies, redundencies, and so on. Basically from my POV I would whiteboard an algorithm to get some common terms, and I would know it was a shit algorithm, like n^k or worse. To her (not trained in CS) it sounded like a decent solution, that would take a while to come up with... a well planned thing. The fights would come of it because she thought I wasn't including her in my thinking about problems we wanted to solve together (and in retrospect I get how it could look that way, particularly when she would point out a constraint I missed and I would just spit out a reworking of the original around the constraint -- doubly understandable things I considered glaring flaws could really be considered trivial since they only add a small penalty (n^2 is not terrible in runtime when n is small to begin with)). Anyway, the moral and tl;dr of this paragraph is: planning stuff is isomorphic to setting up an algorithm. Which moves us into my final stretch of rambling:

Programming is the act of describing a process (meaning sequence of actions here...), preferably in a way as to minimize the number of actions. This is now how I describe my job to people. I use examples like building things, or cooking or paperwork, or whatever, then explain how this related to the computer instructions. Turns out a lot of people actually get this (as opposed to talking about computer languages, or using fancy terms like algorithm).

tl;dr -- programming is just setting up a sequence of actions for a computer. Anything else that uses a sequence of actions can benefit from programming techniques.

Interesting you bring up the gardening techniques. Actually many of the old school algorithms related to hypothesis testing in six sigma were indeed derived from farming techniques. Or rather small trial farms were different theories were tested by dividing the farm into sections.

A previous post on the same subject - might be interesting for people who did not see it before: http://news.ycombinator.com/item?id=454045

I am not sure what "real" means but, I use programming tricks in my non-programming job.

I make big and obvious the important things that I need to remember in a hurry. I hack away at removing stuff that isn't necessary.

A/B testing on dates and on random women I've met in bars. No, really.

The things you cited were real life "tricks" before they were programming tricks. (Military strategy, general problem I suppose, Ronald Reagan and any book on manners, respectively.)

But not to me :)

Programming is the way to sharpen your wits in this respect and the way we codify algorithms means that it is much more formalized and allows for algorithms of increasing complexity.

Sure thing:

Sorting

Exception handling the wife (sorry honey if you read this)

Loop unrolling

You do loop unrolling on purpose? I think loop unrolling is one of the disadvantages we have in real life.

I already made my bed, now can't you do it for me for d in days? It's the same every time! What's with all this premature optimization?

Oh sure I do, especially in cooking. Rather than just repeat the same procedure with cleanup and all, I do all of them then clean up, i.e. chopping peppers, shredding cheese, frying sausage, etc.

I once used quicksort to sort a few hundred CDs.

I needed a big table for my stacks, and when the stacks got small I reverted to a "just put the suckers in order" sort, but basically it worked really well. I was done a lot quicker than I expected.

during college I came into the habit of trying to speak about a class of things in a general way, rather than speaking about one specific thing. this works great for math and computer science. this does not work great with your girlfriend. imagine holding your girl and saying this:

"women are so wonderful. the smell of their hair, the feel of their warmth when you hold them close and they press against your body...".

you might think this sounds romantic. women do not. instead, say this:

"you are so wonderful. the smell of your hair, the feel of your warmth when I hold you close and you press against my body...".

had to learn that one the hard way...

See Jeannette Wing's Computational Thinking:

http://www.cs.cmu.edu/afs/cs/usr/wing/www/publications/Wing0...

"When in doubt, use brute force."

From my blacksmithing days: "When in doubt, get a bigger hammer."

Reply on news.ycombinator.com