31–40 of 136 posts
Holding as much of the program in your head gives you the power to identify what will give you the best optimization. Also this may be the short explanation why good software is written by teams of max 2-3 people!
Psychologists have identified a state of mind called flow in which we're capable of incredible concentration and productivity. The importance of flow to programming has been recognized for nearly two decades since it was discussed in the classic book about human factors in programming Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister (Dorset House, 1987). The two key facts about flow are that it takes around 15 minutes to get into a state of flow and that even brief interruptions can break you right out of it, requiring another 15-minute immersion to reenter. DeMarco and Lister, like most subsequent authors, concerned themselves mostly with flow-destroying interruptions such as ringing telephones and inopportune visits from the boss. Less frequently considered but probably just as important to programmers are the interruptions caused by our tools. Languages that require, for instance, a lengthy compilation before you can try your latest code can be just as inimical to flow as a noisy phone or a nosy boss. So, one way to look at Lisp is as a language designed to keep you in a state of flow.
> Thanks to Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev, and Stephen Wolfram for reading drafts of this. PG, you got the Stephen Wolfram to read this? If so, perhaps you can have a conversation with him about making Mathematica open source :~)?
He gave a great talk on simplicity in nature's algorithms at MIT. I could see a lot of application to programming with his take on simplicity vs. complexity.
http://mitworld.mit.edu/play/147/
Also, he spoke at Startup School in 2005 - really excellent talk you should definitely check out if you get a chance.
http://feeds.feedburner.com/~r/Ycombinator-StartupSchool/~3/...
(For anyone new to the site, you can get all the available Startup School talk mp3's at this podcast: http://feeds.feedburner.com/ycombinator-startupschool )
Naur, P. 1985. Programming as theory building. Microprocessing and Microprogramming 15, 5, 253--261. http://www.zafar.se/bkz/Articles/NaurProgrammingTheory
> Thanks to Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev, and Stephen Wolfram for reading drafts of this. PG, you got the Stephen Wolfram to read this? If so, perhaps you can have a conversation with him about making Mathematica open source :~)?
> Sometimes when you return to a problem after a rest, you find your unconscious mind has left an answer waiting for you. This happens to me on so may occasions in may different areas. While programming, if I have a problem I'll sleep on it, wake up, and see the problem in a whole new light. Also, before writing an essay for class, I will read the prompt throughly. This way my brain starts form sentences without cons…
Awesome essay, Paul. You really nailed this whole phenomenon. It's the first time I've read all these things in one place and it is so very true in my experiences. At my old company, one comment you'd always hear from team members with a new idea was "Hey, I thought of this in the shower this morning, and I think we should ..."
> Oddly enough, scheduled distractions may be worse than unscheduled ones. If you know you have a meeting in an hour, you don't even start working on something hard. God, how I wish more people understood this. It might seem like programmers overreact to even the most minor demands on their time---"What's the big deal? It's only a half-hour meeting!"---but a half-hour meeting can easily kill several hours of producti…