Connecting all my dots..

Does this title ring a bell? If not, do read this lecture by the greatest pirate of Silicon Valley.



Egoistic Electronics student [Year 1994]
Despite all the hype, I couldn't let myself into believing Information technology to be a mainstream engineering subject. So, I opted for Electronics and Communications. That sounded more like a real engineering.

The D-Day - Software engineer born [Year 1997]
During the fag end of my graduation, ironically, not surprisingly though, I was already worshipping software. Like God, it was intangible and omnipresent.

Jack of all trades, master of none [Year 1998]
I could jabber a mouthful on every tech topic under the sun. I used to attend every technical conference and memorize all the jargons and acronyms. With a bit of exaggeration, I could say I was a talking Wikipedia.

The new age programmer [Year 1999]
I was disillusioned with bleeding edge technologies. One fine day, I emerged out of this vicious cycle of learning, unlearning and that is when I decided to focus on the core. It was the time when I read all the classics and wrote some really elegant code. I was surprised to find good books from Microsoft press. Here is a piece of advise - Instead of reading coupling and cohesion theory from Pressman, learn them from code complete. Pick and read any book written by the greats like Plauger, Kernighan, Gerald Weinberg, Knuth.

Over-engineering syndrome [Year 2k]
Now, the new age programmer built palaces even when all it needed was a doghouse. This was the undesirable side effect I had because of over-reading object oriented literature. I painfully read all the books by Booch, Rambaugh and Jacobson. I religiously applied OO techniques with almost no discretion. I read all the design patterns and frameworks and wrote some lightweight ones myself. Layers of inefficiency were being built into the product in the name of abstraction. These premature abstractions soon to be covered up by something known as refactoring. First of all, there is a huge learning curve in learning any framework. Asking developers to throw away your bad framework is unpardonable.

Analysis paralysis Escapade [Year 2k2]
I understood the power of prototyping in discovering the unknowns. I realized that designing a good framework requires domain expertise. It is probably not a good idea to generalize when requirements are still evolving. I was forced to make prototypes. We all try to reuse prototype code. That is such a bad idea. The purpose of prototype is to gain insight, understand the problem. You probably will ignore what I am saying. Even if you understand, convincing your manager is a daunting task. Why will your manager listen to you when the industry didn't pay attention to views of Fred Brooks. Way back in seventies he was screaming in his classic Mythical Man month - "plan to throw one away; you will, anyhow"! Oh by the way, PoC (Proof of Concept) and prototype are one and the same.

Both theory and practice are of utmost importance. Striking a good balance between them is critical. What I found to be very fruitful is learning technology through its evolution and building nuts and bolts by trial and error. I felt that it is easier to explain a complex concept by walking through its evolution. I applied this technique in a Mobile IP article for Dr.Dobb's.

Inclination towards open source [Year 2k3]
I could feel the pulse for the open source, its economics, politics and geography. I have started contributing some pieces of code to Apache projects. I wonder why Apache HTTP server was the last C project from ASF. Why have they become a big bad Java house? I see lot of over engineering happening in open source projects too. In spite of that there is so much learning just by lurking over developer mailing lists. There is a gold mine of code in Source forge waiting to be discovered.

Where do I go from here? [Year 2k6]
Write a decent open source product? Prepare myself to become an entrepreneur?

Six secret ingredients for a successful career in software

These are vague (abstract) enough to stand the test of time..

Conceptualization of obvious things
The unique selling point (USP) of any virtual and intangible form is not its function, performance or quality but its conceptual model. Since Software falls under the same category, conceptualization is a critical thought process that every professional should master.

Take for instance Adobe Acrobat reader/writer marketing strategy - "Reader is free and writer has to be purchased"! Sounds straightforward and lackluster right? Conceptualization of the same statement would turn out like this - "The burden is rightfully on content producer/creator rather than on content consumer or distributor". Which one sounds cool?

Context driven Conceptualization
After mastering conceptualization, the next step is manage your portfolio of concepts. Concepts are highly volatile and hence the containment of concepts deserves the same magnitude of attention as that of cryogenic liquids. Human brain is however overwhelmed with the conceptual bigbang. Here is where 'contexts' come to rescue. Contexts are the natural containers of concepts. Contexts have MxN relationship with concepts.

In layman terms, I don’t remember any grammar rules, but can never forget my english teacher's jokes. How I wish those jokes were in some way mapped to the rules of the language!

Unification of technology
Software engineers are constantly worrying about their domain depletion and spend a lot of time and effort in context (career) switching rather than doing any real useful work. At a high level you can draw parallels even across the diverse technologies. For instance: Session initiation protocol (SIP), a Voice over IP (VoIP) protocol is clearly inspired from hyper text transfer protocol (HTTP). Storage area networks (SAN) work on the principle of separating data management traffic from application traffic; Common Management Information protocol (CMIP) used for monitoring of telecom networks applied the same technique of separating network node management traffic from application traffic.

Burning hay stack to find the needle
I am reminded of a well known theory in economics - "Value is lost with its abundance". The declining prices of consumer electronic items with increase in volume proves this theory. That also explains why gold is precious! We are all taught in our elementary schools or rather brainwashed that "Knowledge is value". Combining both of these theories we can come to the conclusion that "Knowledge is lost with its abundance"!

No doubt, internet has brought information at your finger tips that lead to information overload. The only way to address this is by assimilating knowledge from selective sources. The selection should be based on two sets of filters.

1. Read only classics in the field of your study.
2. Judge the credibility of information before consumption.

Don't forget to unlearn a few things on your way. Unlearning is a liberating process that will override your old hard earned knowledge with new ideas.

Art of loving and living with workarounds
You all would agree with me when I say that you don't need explanation for this.

Science of learning technology by evolution
Learning by evolution is NOT learning calculus in college instead of kindergarten. Learning by evolution is phase wise learning process with a clear focus on what to learn in each phase. Start with the study of the fundamentals or basics. Though this sounds obvious it’s not easy. After you learn the basics, you immediately apply them. You will then figure out that you need to know more. When you get to 'gotta know more" stage, learn about the limitations, disadvantages. Then for each limitation, research on how the a new work around circumvents the limitation. You are now aware of basics and also workarounds. At this stage, there two paths that can be taken based on your capability:

A. Get into the vicious cycle of learning workarounds of workarounds.
B. Stop learning and start working on unsolved problems

Option B is risky and hence less exercised. If you choose option B, then 'know-why' is any day better than 'know-how'. However, if you excel in option A you will be known as solution architect;-) I am not here to influence your decision making, as my goal ends with creating awareness.

Bull's introspection!!

Powered by Google image search

The search strings were "bull man" and "bull man computer". I only claim copyrights for the bull's sentiments and hence, cannot not be held responsible for plagiarism;)