Archive for June, 2008
Programmer Vs Nonprogrammer: Why it’s not healthy to think “or” but wise to think “and”!
As Bill Gates retires, Joel Spolsky has written a great article about what it was like to work for the world’s most successful entrepreneur. It’s definitely a must read article. If you love real stories, you will love this story too.
In this article, Joel mainly talks about Bill Gates’ detailed oriented approach in running a giant software company and his passion to get involved in small technical decisions while running the business as well.
What did I take from all this? Bill Gates was amazingly technical, and he knew more about the details of his company’s software than most of the people who worked on those details day in and day out. He understood Variants and COM objects and IDispatch and why Automation is different than vtables — and why this might lead to dual interfaces. He worried about date and time functions. He didn’t meddle in software if he trusted the people who were working on it, but you couldn’t bullshit him for a minute because he was a programmer. A real, actual programmer.
Watching nonprogrammers trying to run software companies is like watching someone who doesn’t know how to surf trying to surf. Even if he has great advisers standing on the shore telling him what to do, he still falls off the board again and again. The cult of the M.B.A. likes to believe that you can run organizations that do things that you don’t understand. But often, you can’t.
Though Joel strongly gives Microsoft’s success’ credit to Bill Gates’ technical abilities, I tend to disagree with him to certain extent. I think that apart from Bill Gate’s great technical knowledge and passion, he also has very sharp business acumen. And for example, that’s precisely the reason, he could license DOS to IBM though it was originally programmed by Tim Paterson. I firmly believe that just because you can write the code doesn’t mean that you can also able to sell it. You got to have the strong knack to sell the products and make money.
Also, as a counter example, when Steve Jobs founded Apple, he was a nonprogrammer, but he still runs one of the most innovative and successful companies in the world. He didn’t know how to write the code, but he knew how to configure a team which knows how to develop the code. He didn’t know how to design a product, but he knew what needed to be designed in the product. He is a visionary who has a great taste and powerful salesman aptitude. So being a nonprogrammer he could still run and grow Apple to a highly respectable scale.
I think Joel’s view about nonprogrammers is little extreme. Sure, knowing programming and having technical knowledge can give you an unfair advantage over other MBA people, but similarly understanding business world will also give you an advantage over hackers and programmers.
Finding balance and acquiring knowledge from both worlds is the key!
Have a great week ahead!
The Experienced Vs. The Novice
Few days ago, guys at 37Signals posted a very interesting excerpt from “A Pattern Language” by architect Christopher Alexander. In that excerpt, Christopher Alexander compares the work of a fifty-year-old carpenter with the work of a novice.
All those detailed design decisions which can never be worked out in advance on paper, can be made during the building process. And it allows you to see the space in three dimensions as a whole, each step of the way, as more material is added…
The essence of this process is very fundamental indeed. We may understand it best by comparing the work of a fifty-year-old carpenter with the work of a novice. The experienced carpenter keeps going. He doesn’t have to keep stopping, because every action he performs, is calculated in such a way that some later action can put it right to the extent that it is imperfect now. What is critical here, is the sequence of events. The carpenter never takes a step which he cannot correct later; so he can keep working, confidently, steadily.
The novice by comparison, spends a great deal of his time trying to figure out what to do. He does this essentially because he knows that an action he takes now may cause unretractable problems a little further down the line; and if he is not careful, he will find himself with a joint that requires the shortening of some crucial member – at a stage when it is too late to shorten that member. The fear of these kinds of mistakes forces him to spend hours trying to figure ahead: and it forces him to work as far as possible to exact drawings because they will guarantee that he avoids these kinds of mistakes.
The difference between the novice and the master is simply that the novice has not learnt, yet, how to do things in such a way that he can afford to make small mistakes. The master knows that the sequence of his actions will always allow him to cover his mistakes a little further down the line. It is this simple but essential knowledge which gives the work of a master carpenter its wonderful, smooth, relaxed, and almost unconcerned simplicity.
After reading this, I could easily correlate my current situation with this explanation. As a novice web developer, this is exactly what happens to me. While developing a new feature, or while making changes in the database schema – I don’t understand if this may cause unretractable problems at the later stages. So I take more time and also make changes more cautiously. And that’s why experience in building similar stuff is very important while building an application. Though, I had asked in my previous post if experience is really needed while starting a startup, after going through my current situation, and reading this excerpt, I can say that experience is very important. In short, we can build things in much efficient way.
But we also know that lot of successful startups were founded by young graduates or even school dropouts. And we think that they were also inexperienced but they still did it, and so we can also do it. I think that’s a mistake. In most of the cases, those young graduates or dropouts were hacking stuff since they were kids. They knew how to build the stuff, and that’s why they were in the position to start a startup. But at the same time, not having enough experience doesn’t mean that we should give up starting a startup. We should start acquiring all those abilities that are required to start a startup and to run a company without further dues. If not today, at least tomorrow those abilities will help us to start a startup. So let’s get started with building the stuff – the real stuff!
Have a great weekend ahead!
When something goes wrong…

Blame Token
Once in a while, we land up in a situation when something doesn’t go right as expected. Usually, in such situations the most common behavior which we see is we tend to blame someone else for what went wrong. I think that’s the biggest mistake we generally do.
What’s wrong in blaming someone?
1. It’s ethically wrong:
As we already know, it doesn’t make sense morally. We are putting someone else in a weird situation for which that person was not even responsible.
2. We don’t learn:
We are loosing the great opportunity to learn. I think this is a terrible mistake. When we blame someone, we are also turning down our responsibilities. We are not even attempting to understand what went wrong, what were its causes, and how it can be corrected. I think the only way we can make progress is learning from our mistakes.
3. We undervalue our importance:
We are giving the importance to other person in such situations. When we blame someone else, we are indirectly indicating that if the required thing would have worked good as expected, that person would have been responsible for it, as he is also responsible for its failure.
In short, when something goes wrong, don’t blame someone else, instead learn from it.