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

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

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.

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.

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

  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

  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

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

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.

Sure thing:

Sorting

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

Loop unrolling

"When in doubt, use brute force."

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.

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.

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

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

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

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

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?

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

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.

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

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

I swear a lot.

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.

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

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.

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.

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

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.

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