
Ask HN: Do you use programming tricks in real life too? - jacquesm
I suddenly realized that I'm practicing 'programming tricks' in real life all the time.<p>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).<p>For instance, assume nothing, trust but verify, be strict in what you send but forgiving in what you receive and so on.<p>Those all have real-life equivalents for me.<p>Professional deformation or useful trait? Do you have it too ? In what way ?
======
silentbicycle
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.

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

~~~
cellularmitosis
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".

~~~
ScottBurson
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.

------
icey
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.

~~~
seles
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.

~~~
icey
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.

~~~
seles
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.

~~~
PebblesRox
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.

~~~
seles
Thanks

------
feral
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...

------
jkempf
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.

~~~
mahmud
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!

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

------
dstein
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.

~~~
kleiba
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.

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

------
jamesbritt
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.

~~~
tricky
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.

~~~
arethuza
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".

------
ggchappell
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?).

------
alextp
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²).

------
jhuckestein
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.

------
franck
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.

------
there
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?

~~~
aquark
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.

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

~~~
jacquesm
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.

------
praecipula
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.

------
etherael
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. ;)

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

~~~
jacquesm
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 ;)

~~~
sophacles
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".

------
igorhvr
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.

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

------
masmullin
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.

------
ashishb4u
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!! :)

------
adamtj
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.

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

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

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

------
styrmis
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.

------
DrStalker
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.

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

~~~
mapleoin
So what's taking so long?

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

------
Super_Jambo
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.

~~~
gssgss
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.

------
TeMPOraL
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.

------
ajennings
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).

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

------
vault_
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.

------
RevRal
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.

------
sophacles
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.

~~~
sundae79
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.

------
igorhvr
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>

------
mmphosis
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.

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

------
albertsun
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.)

~~~
jacquesm
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.

------
gte910h
Sure thing:

Sorting

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

Loop unrolling

~~~
mapleoin
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?

~~~
gte910h
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.

------
DennisP
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.

------
cellularmitosis
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...

------
kjhughes
See Jeannette Wing's Computational Thinking:

[http://www.cs.cmu.edu/afs/cs/usr/wing/www/publications/Wing0...](http://www.cs.cmu.edu/afs/cs/usr/wing/www/publications/Wing06.pdf)

------
gloob
"When in doubt, use brute force."

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

