I attributed a lot of this 'effectiveness' to developers who are lazy.<p>There have been times when I automated things and that was because I wanted to avoid repetitive work. I have never been able to automate something I had not manually done 2-3+ times, but once I did I knew what I needed to do to avoid manual work and make the process error free for next time same operation was needed. If someone else was dictating what they needed, I would not have been able to build my tools as effectively.<p>To me, a good developer is a "maker", who builds tools. For us the raw material is a computer and some free time, which makes experimentation and evolution of our tools easier compared to other professions.
He neatly explains why traditional, say, "reasonable" management does not work in IT:<p>- Objectives are a way of saying prove to me first that you know where you are going before you go.<p>- We’ve come to believe too much in metrics and accountability.<p>- There’s no systematic way known how solve ambitious problems. (Otherwise they would have been solved already.)<p>For example, the original Google Search project succeeded, exactly because none of this was around. Traditional management only works for repetitive processes. Organizations that revolve around traditional management are incapable of innovating.
"As Schopenhauer says, when you look back on your life, it looks as though it were a plot, but when you are into it, it’s a mess: just one surprise after another. Then, later, you see it was perfect."<p>Weird. When I look back on my life, I see blunders, randomness and missed opportunities. There's a great deal that I would change if I could do it over. I'd have thought that was the same for most people.
I certainly disagree with this bit, <i>"There’s no systematic way to know how solve ambitious problems. We just don’t know what will lead to what. The future is a fog. An ambitious problem is not deciding what to have for lunch, it’s more like curing cancer or creating an AI."</i><p>I have always started on the solution to an ambitious problem by asking "what would have to be true for this to be solvable?" and from each of those things working backward until you get to things that are all true now. Then you can start solving the "almost" true things and work forward to the ambitious solution at the end.
I'm currently listening to an account of the de-centralized command structure Gen Stanley Mcchrystal put in place to combat Al Quaeda in Iraq and the taliban in Afghanistan. One thing that is clear is that in a fast paced environment (be that the theater of war or a start up) top down rigid command doesn't work. All this is really saying that the the organization that gets through a feedback loop as fast as possible wins. You can call that the OODA loop, lean, holocracy or whatever you want.<p>I'm strongly in favor of giving up centralized control in the interests of allowing emergent behavior to tackle opportunities as fast as possible. Leadership to me should be:<p>* Set the direction<p>* Gather smart, motivated people<p>* Create an environment that gets everyone on the same page<p>* Get the fuck out of their way.
I guess I'm more amazed at how much energy goes into relatively minor advances or even in going backwards. Like the proliferation of frameworks, the difficulty in cross-platform development, how hard scaling remains, etc.
Isn't a big part of information technology's rapid pace the fact that much of it happens in a virtual space instead of the real world? I wonder if civil engineering would move as fast if buildings could be built and torn down as fast (and as cheaply) as computer programs, and if building materials' efficiency could be improved at the same pace transistors can be miniaturized?
"Information technology" is over a century old. IBM has been in business for more than a century. FORTRAN is over 60 years old. C and Unix are over 40. So is the Intel 8080 microprocessor. It's not like this happened overnight.<p>Both electric power and railroads were deployed faster.
Nice essay. Love the premise of how working around a problem can lead to a direct solution instead of working directly on a solution. It's a very important point.<p>But there is an exception to his argument that he should have acknowledged for the essay to really take hold: there is one area where we can work towards clear objectives that actually help solve problems we don't understand. That area is making existing solutions more efficient.<p>Moore's Law has carried a huge load in the advancement of IT. Ideas that were simply speculations become easy-to-accomplish when technology gets commoditized. Things that used to take months can happen in seconds. That opens up all kinds of new possibilities.<p>IT is full of folks making stuff more efficient. That stuff can be hardware, software, or just "things people do", like hail a taxi. The more efficient we make everything, the easier it is to create and combine stepping stones. That takes a good idea and makes it even better.
title naming in hackernews is so copy-cat. this is the 3rd time I see a title "the unreasonable effectiveness" of X. After the first very successful post.