>Design and Architecture

>I wonder how I missed this artima blog. It’s an interesting way to present the difference between design and architecture.

>Technical Ladder Trap

>Technical Ladder Vs Management Ladder: Part 2

In Part 1, I talked about the possible directions that a techie’s career can take. In part 2, I want to look at the dangers of falling into what can be termed as Technical Ladder Trap. The technical ladder trap is nothing but a way to gradually become useless as a techie. How do you become useless as a techie? Going back to the economics introduced in Part 1, you become useless when there is a struggle between your Y (the money that your company earns because of you) and your X (the money that you are getting from company). In other words, your X is growing, Y is stagnant which puts a pressure on the ratio that must be maintained between the two. In yet other words, you have started drawing more money from the company (or intend to draw more money from the company) without increasing the value that you add to the company.

There are multiple ways one can fall into this trap:

1. Getting lost in the nitty-gritties of technology and not focusing on what’s important for the technology consumer i.e. your company’s customer. So, you think that given 2 weeks time, you can develop and implement an algorithm that can significantly cut down the start-up time of your application. But does it matter to your customer? May be the customer is fine with the startup time but is really concerned with the response time? Irrespective of the coolness co-efficient of your algorithm, it’s just a waste of time for you and waste of money for your company.

2. Limiting yourself to low end of technology development value chain. Granted you can do quick work in Python. But can you grow up to write an application in Python? Can you make a scalable/extensible/insert-your-favourite-word-here type of design in Python? Can you exploit the availability of free tools in your system? Can you exploit the heuristics to make optimizations?

3. Limiting yourself to a small subset of technologies. So, you are good at Java. But can you see that a small portion of your system will do better with C because of performance gains. And another small portion will do good with scripting because of productivity gains. Which part of the application should be multi-threaded, which part multi-processes. Do you use RMI/XML/SOAP/whatever-new-thing-comes-in for your inter process communication? Different technologies have different strengths and weaknesses. They are developed with different goals in mind and the one you know may not be the best for your purpose. Also, technologies become obsolete almost as fast as they gain prominence. You have to keep the learning process on.

>Objects and Languages



Jim Waldo has been in deep thoughts about objects and their dependence on languages.

“I want to ask the question of whether objects are something that we can believe in without believing in the objects of a particular kind expressed in a particular language, or if there is something more abstract about objects.”

I believe, only the state of an object is independent of the language but niether the expression of that state nor the interaction of the object with others is indenpendent. We can notice this even outside programming paradigm. Let’s take the case of a piece of iron. It has a state that is independent of all the languages of the world be it English, Hindi, Japanese or whatever. However, when an observer looks at that piece of metal, his/her mind will choose one language and start thinking about that piece of iron in that language. This thinking will primarily be a description of the state of this iron piece and its relationship with its surroundings. Here, the language he/she is thinking in makes a profound impact on what that objects becomes to the observer.

To summarize, only the state of an object is independent of the language that too as long as it is not expressed.

>Design and Testing.

During all these years I have spent in tech, I have observed that design is considered an activity for development and deployment. You sit with a white board and design your system around scalability, performance, modularity, blah, blah. Nothing wrong with it except that they miss out one very important thing: Testability. So, design is an activity with far reaching effects on development, testing and deployment.

The testability of a system merits design consideration as it plays important role in tackling two very hard and real problems of software development.

1. Time and Resources problems: Testing needs huge number of resources and tremendous amount of time. The easier it is to test a system, the smaller is the cost to test it. The cost advantage is seen in terms of resources as well

as time.

2. Stability and Functional problems: Not only that the time and resources are expensive, they are also limited. In the real world, testing gets fixed amount of time, and whatever bugs can be found and fixed in that timeframe are the ones that make it into the release. Essence – if your system is hard to test, chances are most of the bugs will not even be discovered before the release.

Now, it would seem that I would start advocating stuff like extreme programming. and Test Driven Development. Oh, it is such a natural thing to do while stressing the importance of testing. But I am not in that mood. And I am not in that camp. Period.

>Evolution of a Programmer.

Long time back, vishal gave me a funny and completely true perspective on how a programmer evolves after entering professional life. I just can’t help sharing it here (especially after I alluded to that evolution in my previous post Technical Ladder Vs Management Ladder.

A programmer, in fact any techie, goes through three phases of evolution:

1. Jackie Chan – You are young, smart and energetic. Even though you can fight, you mostly dread the enemy (mostly the powerful ones). Your fights tend to go on longer and you are mostly beaten up by the enemy. Only towards the end, do you get a control on the situation. You don’t use any sophisticated tools for fighting, you do it mostly with hands OR whatever you can lay your hands on (including broom).

2. Bruce Willis – You have developed a passion for fighting now. You have learned to use tools that boost your productivity by killing enemies faster. Also, you keep a tight control over the enemy right from the begining. But you still can’t do it without getting hurt. You are so involved in fighting that you have blood running down your face and you run bare-foot on glass pieces.

3. James Bond – This is what you eventually become. Calm, fast and effortless. You have equipped yourself with an array of extremely sophisticated tools. With these tools, you can not only kill scores of people by just turning the cap of your pen, you also know how to keep yourself unhurt. Finishing a task is just a cinch for you. And by the way, you have also learnt to indulge in non-technological pleasures

>Technical Ladder Vs Management ladder – Which one is for me? Part 1.

A fundamental question at 4 years of working life. Isn’t it? Ok, you may be asking yourself this question at 2 years of job-age or 6 years of job-age. But like it or not, there is no escape. As so many people (mainly job consultants) say, “It’s your career and if you don’t control it, someone else will.”

Am I here to tell you which one is for you? No. Am I going to give an objective comparision of the pros and cons and help you take a decision? No. I assure you that I won’t leave you in any better position to decide than now. Hopefully, I would at most make you consider it an important decision with some interesting observations. Still, with me? Good, let’s start.

No one can doubt (including myself) that there are n possibilites in which one’s career can develop and take a tangible form. But let’s not bother about the nitty-gritties and let’s discard the rare cases when we are out to discuss the *most probable* career directions. As Joe Marasco says in ‘Three Phases of Life’:

A simple model that people can understand and apply and that works eighty percent of the time is more useful than a complex and hard to use model that works ninety-five percent of the time.

1. There are those students who get excited by anything and everything that can be called technology. Their career direction is clear right from the begining (even though the career path is to be laid out).

2. And then there are those who find technology unhappening/uninteresting/not-cool/not-my-cup-of-tea. Producing technology is no fun for them, but using and selling is. They go on to become MBAs and the likes.

3. Then there are remaining poor fellows who enter techie job because they have studied technology at college. They are ‘out’ to make a career in technology without knowing/understanding what career they can make out of it. Whether they are good at it or bad is beside the point. What matters is they are ‘in’ there without having a clear understanding of why and without a notion of what-next!

Ok. So, they jump into technology with great vigour. They learn a lot of things, produce some good things, shoot the stars off the sky and become valuable to the company and in general, like so many other people, do well in their job. They earn applauds and two ladders are thrown down from the heaven in appreciation of their good work. One is called Technical Ladder and the other Management Ladder.

This marks a turning point in one’s career. In my experience, even though the process is gradual and you can see from far that these two ladders lie in your path, you don’t notice them. And then one fine day, you suddenly realize that you have got to make a choice.

Before I proceed any further, let me dive into a little bit of economics. Why economics? Because economics is what takes you to office everyday even though you would have preferred sitting on that cozy chair in your living room and sipping beer whole day. You might be tempted to argue that you go to office for doing good work and not for drawing pay-cheque. But the fact is the only reason you go to office to do all the cool work rather than sitting at home and doing even cooler work is that you get paid for going to office. So, you go to office for money and work hard for more money.

That’s your side of the story. Let’s see from your companies’ side. Why is your company paying you money and is willing to pay even more in future? Because for every $X you get from company, the company makes $Y. Let’s say (just say) Y == $2X. It could be $1.1X or it could be $11X, but let’s say for this particular case, it is $2X.

Now, when would your company be willing to increase X? There may be multiple reasons like fear of losing you (nobody knows/understands your code, your project is close to completion and the company can’t afford losing you for some time, X is less than the market rate anyway), you have laid your hands on some trade secrets that the company can’t afford going out etc etc. Irrespective of the total number of circumstances, there is one reason that always outshines all others and that is (hold your breath) … you increase Y!

Hmmm. So, If you increase company’s Y, company will increase your X (may not neccessarily be in same order but that’s the rough calculation). Even though it sounds all too obvious and dumb, it is the most useful and often forgotten principle of career growth.

Let’s take a close look at this principle now, If you were drawing $1 per month, the company was making $2. If you want to draw $2 now, you should help the company make $4. For $4, the company should make $8. So, there are two conclusions that can be drawn:

1. X will increase only if Y increases. Something that we have already established well enough. 2. The increase in Y will be always be a multiple of increase in X. It means if you want 1 more dollar, you’ll have to earn 2 more dollars which is 1 more than what you want draw. But that is the case for every single dollar that you want to earn. So, if you want to earn 4 more dollars, the company has to earn 8 more dollars which is 4 more than what you are earning. This is called ‘value addition’ and is the most widely known and least utilized principle.

This is where the fundamentals of economic theory take back seat and we talk about how they apply in our day-to-day job.

Any techie would go through the typical evolution of Jackie Chan, Bruce Wills and James Bond. When you start working, you are Jackie Chan and are drawing $1. Soon, you learn how you can avoid being beaten up and easily overpower your enemy. You evolve to become Bruce Wills and start drawing $2. After fighting the enemy again and again, you become so adept at it that it becomes a cinch for you. You could kill scores of people just by turning the cap of your pen. All your work looks so perfect and you do it so effortlessly! This is you as James Bond of technology drawing $3 (or may be even $4).

Here you are as The James Bond of technology; perfect and effortless. The biggest challenge facing you now is how do you start drawing $5. You are already close to perfect at your work. So, you can’t do it better than you do it now. You are already fast, so, you can’t finish your job any faster. Basically, there doesn’t seem to be a way for you to increase Y anymore and hence, your X has hit a glass ceiling!!

Fortunately, life is not so harsh. There are still ways to increase that Y but it would require you to take a fresh look at your job description. You can change broad job definition from ‘going out in open to kill’ to something like ‘leading a team of other James Bonds in Making’ OR ‘developing new techniques of warfare’ OR ‘strategising a war’ on and on.

Let me summarize all this economic sense and its impact on your career. You can’t remain a programmer forever if you want to draw more and more money out of your company. You have to move up in the value chain and change your job definition almost as soon as you become good at it. It’s a never ending cycle and it hits you for the first time at approximately 4 years of job life.

So, what is it I was talking about? Ah, the career directions for techies OR better still Crossroads at Year 4…

From here, your career can take three general directions (oh, it can take n directions but we’ll consider only 3 to keep our model simple):

1. Technology Guru. These are the guys dev teams go to before they start the work on a complex project. They are also highly sought after by teams that completely mess up a project and are trying to figure out ways to fix the mess. All of us have read about them, heard about them, seen them and may be even worked with them. And believe me, not all of them are eccentric and very few of them have pony-tails.

2. Product Management. What if you were to tell James Bond, ‘Mr. Bond, you have killed enough enemies. Why don’t you now go around the world and meet country leaders/warlords to understand their pain areas. We can then do profitability analysis and develop new products. And you could take the responsibility of getting those products developed and selling them to different countries’? That’s product management for techies.

3. Project Management. Much more often than not, it is an outcome of your indecisiveness. Very few people choose to be project manager. Most of them just become one. Why? Because it seems to you the ‘natural evolution’, though in fact, it is the path of ‘least resistance’. You enter job and learn to write code. You get some experience, you learn to write good code. You get more experience, you write twice the code with half the bugs in same timeframe. Then? That’s your saturation point. You can’t justify increase in that hefty pay-cheque you are already drawing unless you beat your saturation point.

Nobody will ask you to become a technology guru in exchange of pay-rise. You become one out of your own choice (and hard/smart work). Nobody will ask you to get into product management. You get into it out of your own choice (and hard/smart work). So, your company says: Ok, now that you can’t do it any better than you are already doing it, why don’t you take this bunch of guys who can do it better than they are doing it now and help them out. So, you are given bigger work with some deadlines and you make use of your ‘team’ to get it done. Which means you listen to their complaints, answer their questions, clarify their doubts, teach them how to do it as good as you can do it, prevent them from leaving, press them for finishing, on and on and on…

I might have made ‘Project Management’ sound like a terrible thing to do but as a matter of fact it is not at all like that. And some people do choose to get into project management and it is as good a choice as the other two. The only sad aspect of this direction is that most of the people just get into it without realizing that they had a choice AND they could have done something else.

I am at the end of this blog entry now. I am sure (as I stated early on) that after reading this blog, you are in no better position to decide which ladder is for you. Well, that was not the goal and you won’t know till you try it out anyway. However, I am sure you now understand that this is a decision you can’t avoid unless you don’t mind the path of natural evolution and become a project manager (which is, of course, not a bad thing at all).

Going forward, I hope to write some more interesting stuff on this topic. Again, not to help you make a decision but to help you understand what this decision might mean.