Tekhne

This. One thousand times this. The author's subjective judgements of other people aside, from my point of view, mandatory pair programming is a plague on the software industry. If others want to engage in that practice, cool, but I refuse to work at an employer that requires pair programming. I find requiring it to be grossly insensitive.

"First they came for the Socialists, and I did not speak out— Because I was not a Socialist.

Then they came for the Trade Unionists, and I did not speak out—Because I was not a Trade Unionist.

Then they came for the Jews, and I did not speak out— Because I was not a Jew.

Then they came for me—and there was no one left to speak for me."

—Martin Niemöller

This analogy is flawed, and I think represents the exact problem developers experience with non-developers. There's an underlying assumption that we know what walking or a taxi are. We don't. In this analogy, developers would need to invent both before giving an accurate estimate. The methods of transport are the mechanism for delivering the result of arriving at the desired destination. Software development projects are also about creating the mechanism for arriving at a result. The software is bespoke almost by definition, or you could go buy it off the shelf. Bespoke software is unknown. It's invention. We may be able to apply past experience inventing similar things to our estimations, but there is always some amount of uncertainty. Sometimes there is a lot because we've never built anything like the thing requested. We often may not even understand what is being asked for. If I don't know what a car is, asking me how long it will take to invent one so that you could use it to get to the train is inviting trouble.

My advice is that you read this book:

http://www.amazon.com/Art-Happiness-Guide-Developing-Importa...

This downgrade may just be the first sign of real problems to come. For detailed coverage of the coming US financial storm see the documentary I.O.U.S.A. from former U.S. Comptroller General David Walker (I've seen it on Netflix streaming).

http://www.iousathemovie.com

I absolutely 2nd this suggestion! It was really fascinating. There were some dry parts, but mostly I couldn't stop reading (actually, I did the audiobook).

Actually, bash completion DOES help with long arguments or any arguments. It's true that you have to invest the time to write a completion script tailored for the commands you're interested in, but it can definitely be worth it (e.g. git completion).

OT: We're so used to tech buzzwords that sometimes we don't realize our secret language sounds odd. Just look at the title of this post literally. It's pretty hilarious.

If you read the book "Learned Optimism," you'll see that the research shows this to be a bad strategy. All things being equal, you're more likely to succeed if you have an optimistic or best case view of things, unless the consequences of being wrong are dire. Pessimistic views tend to be more accurate, but also less successful.

Yea, I for one would welcome fast, comfortable, ubiquitous trains. Also, it would be nice if America could really embrace ideas like work from home or Results Only Work Environment in jobs where that makes sense. In my current job, there's no reason I couldn't do 98% of my work from home, except that management is scared that they'd lose control, which is really ridiculous on many levels. This is a new era and some organizations are managing people using techniques from 50 or more years ago. Techniques that have been scientifically shown to be a bad idea in certain jobs.

> ... Americans will still get up tomorrow and drive their gas guzzling SUVs ...

Let's say that I'm an American with a gas guzzling SUV. For the sake of discussion, what would you suggest are my better alternatives (taking into account the money I've already invested in the SUV)? How would those alternatives help fix the current BP problem? I'm not trying to be contrarian. I would like to start a discussion here.

2,500,000,000 barrels / 150,000 barrels per day / 365.25 days per year = 45.6308464522 years

I don't think it's fraud. It's breach of contract.

You're right. In fact, I have my vimperator setup so that it automatically does this for Google Reader and GMail, and only for the relevant tab (i.e. if I hit "v" to view a Reader article, the pass-through turns off on the new tab). I did it with this statement in my .vimperatorrc (Linux):

autocmd LocationChange .* js modes.passAllKeys = /(google\.com\/reader|mail\.google\.com)/.test(buffer.URL)

Does this really work? I've Googled around, and it looks like some/most of the junk mail you do this to won't actually make it back to the sender, but will just be disposed of by the post office.

Turn your outside, rear view mirrors out on your car to completely expose your blind spot. When done right, you should have a continuous field of vision by scanning your eyes from your inside, middle rear view mirror to the outside mirror, and then by turning your head very slightly while still scanning your eyes to catch the cars directly to your sides. It's disorienting at first because you can't see the sides of your car, but that's rarely useful anyway, and when it is, you can just move your head until you can see what you need to (e.g. when parallel parking). You'll get used to the setup pretty fast. I can't count the number of times this hack has saved my butt on the highway.

I second that. I'm a vim lover anyway, but vimperator has been awesome for me. I had RSI problems and this really helped me to reduce my usage of the mouse. Like vim, there's a learning curve, but there are very useful corners to explore.

Reading on the toilet is actually bad for your lower intestines. It can lead to health problems. You want to minimize (within reason) the time spent sitting over a hole like that.

I like to start with the underlying structure of the data as well, which for database-driven web sites means the schema.

"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious." -- Fred Brooks.

Unfortunately, I don't have source in front of me, but I've read some research that indicates that subvocalization is actually necessary for full comprehension, and that claims to the contrary are apocryphal. It's probably best to investigate before trying to eliminate subvocalization.

There's an alternative to the Readability tool called Clippable: http://brettterpstra.com/2009/11/03/clippable

This article follows a line of reasoning about quality which seems to lead to the conclusion, in part, that Apple makes superior products. My question is "compared to what?"

The conclusion is drawn based on the fallacious view that the properties optimized by Apple are universally important. Britney Spears may be hot and rich, but I wouldn't consider her a quality mate. She doesn't meet the minimum set of criteria I'm looking for. In the same vein, not all of Apple's products optimize on properties I care about (e.g. open source, full control of configuration, etc.). Lots of other people probably disagree on both counts, and that's okay.

The point is that while I agree quality is important, it's just as important to know what properties of a thing you're judging or optimizing, and why. This is especially true since the resources for producing anything are finite.

I would add to this that it's important to view optimism and pessimism in the face of risk as a conscious choice. Which view you take is your strategy for acting in the face of that risk.

The research presented in the book "Learned Optimism" by Martin Seligman more or less tells us that people who make this choice consciously have the highest rates of success in life.

The rule, then, is if the consequence of taking the risk and failing is dire, you should be pessimistic, otherwise, always be optimistic. That is, if failing would be catastrophic or really bad, believe that the worst will happen and act accordingly. If the consequence of failure is trivial or not a problem, believe that the best will happen and act accordingly.

Actually, I think vim comes with pretty good Python support by default. I'm using vim 7.1 and there's, for example, a good python.vim syntax file that came with.

There seems to be some Sun-focused FUD and Linux-focused fanboyism flying around here and on Kirk's blog. Obviously, that's no way to evaluate competing solutions. We need facts. We need apple to apple comparisons of hardware and operating systems, where we can get them.

Of course, every /serious/ business can and should get into the details, but for the sake of argument, I invite you to compare a couple apples from the barrel: Sun Microsystem's Sun Fire X4150 (used by Kirk's site), and Dell's PowerEdge 1950 III.

They support /very/ similar hardware options (rack units, CPUs, memory, network, internal storage, out-of-band management, power, expansion slots, etc.), have roughly the same price depending on options (~$7500), and run roughly the same major software (Linux, Solaris, VMWare). Based on that one example, I don't see how Kirk justifies decrying Sun.

I could go on with more hardware or a light comparison of Solaris vs. Linux, but you get the point. Stop with the hyperbole and try presenting facts in a digestible format.

I agree with this advice for the most part. Nevertheless, I would insert insurance (health, disability, auto, etc.) between emergency savings and long term investing. Choose policies that are appropriate to your life needs, but definitely do it. It's harder to do when you're living hand to mouth (e.g. running a start-up), but it's a means of protecting your life, assets and investments. I've had people close to me who had their net worth wiped out by an accident. My $0.02.

Quick nit: that headline should read "What If...It WERE Easy to Write Firefox Extensions?" due to the subjunctive mood of the verb.

I wish I still had the links handy, but there's over a century's worth of research out there showing that it's a bad idea to go over 40 hours in a workweek for any extended period of time.

Of course, everyone's different, but I've noticed I have 4-6 hours of productive time in me per day for knowledge work (e.g. programming). I'm guessing I could get multiples of 4 provided there were long breaks in between, enjoyed what I was doing, and wasn't constantly being interrupted.

When people say "multitasking," I think they really mean "heavy context switching." It's important to re-frame the idea because actual multitasking is /extraordinarily/ difficult. It takes years or decades to master multitasking in even one, very specific arena (e.g. playing the drum set, or understanding two conversations simultaneously).

Heavy context switching, on the other had, is more readily doable by human beings, but still highly inefficient. It would be much better if people focused on prioritizing work more effectively, and then proceeded in a serial manner. Of course, prioritizing work is not easy, especially in complex systems, but the time freed up from constant context switching would help.

Edward Deming (and perhaps others) recommended this idea several decades ago. It's nice to see that 37signals is finally catching up though.