I came across this quote which i copied down from somewhere: "A good programmer, in everyday work, is one who can communicate well with users, managers, and other developers, who can write clean, maintainable code, and who can choose the best tools, architecture, and techniques in putting together a solution.".
It may be good to have such brief definitions for roles within an organization - often people get confused or lost in the daily rush about competencies required for the role they are supposed to perform. Similar to how companies are supposed to have vision and value statements, I think it may be good to have personal vision and value statements which one can tune over a period of time.
control
I have been thinking about the level of control one should have on team and project without being a control freak. It is said that with a good manager, people will not feel like they are being managed. One idea that stuck to me from the book Peopleware is, you put a person on a job and if you trust him with it, don’t try to second guess and rob him of the chances to make decisions.
There are couple of types of managers – those who came up the ranks and know how to do the job and those who don’t know the nitty-gritty of their team’s day to day job. If you think you know more about how to do something than your team member, how do you control the urge of doing the job yourself instead of teaching them how to do it without actually doing it? If someone else is taking 10 days to do something that would take 1 day for you, can you grit your teeth and let him or her go through with it and learn?
On the other hand, one downside of having a manager who don’t know or don’t have capability to comprehend the details of job is explaining things to him in layman’s terms all the time and answering umpteen questions on progress and status and such.
It is a balancing act to reduce dependency, delegate authority and at the same time make sure the task is delivered.
Following are some things I would like to practice:-
1. Transfer knowledge upfront as much as possible for people to be able to do the job. Equip people with what they need or rather make sure that they are setup for succeeding.
2. Let them take decisions, you may hint or suggest course of action, but avoid making decisions for them.
3. Check progress, but not every hour of the day. Give meaningful feedback, not once in 6 months.
There are couple of types of managers – those who came up the ranks and know how to do the job and those who don’t know the nitty-gritty of their team’s day to day job. If you think you know more about how to do something than your team member, how do you control the urge of doing the job yourself instead of teaching them how to do it without actually doing it? If someone else is taking 10 days to do something that would take 1 day for you, can you grit your teeth and let him or her go through with it and learn?
On the other hand, one downside of having a manager who don’t know or don’t have capability to comprehend the details of job is explaining things to him in layman’s terms all the time and answering umpteen questions on progress and status and such.
It is a balancing act to reduce dependency, delegate authority and at the same time make sure the task is delivered.
Following are some things I would like to practice:-
1. Transfer knowledge upfront as much as possible for people to be able to do the job. Equip people with what they need or rather make sure that they are setup for succeeding.
2. Let them take decisions, you may hint or suggest course of action, but avoid making decisions for them.
3. Check progress, but not every hour of the day. Give meaningful feedback, not once in 6 months.
JUG
I attended a java user group meeting yesterday. Topic was State of Aspect oriented programming.
20% of audience had used aspect oriented programming in their projects. Compared to the demos given using Ant, JaaS, AspectJ, Sping, Log4j etc, I felt like a barbarian who still use System.out.println(“I am here..”) for debugging and Notepad for coding.
I am convinced that these tools or methodologies increase programmer productivity, code maintainability and durable design. But how many actual customers who pay for IT projects understand or even care about using these? Then again I guess it is not a choice to be made by customers, but by the programmers.
That leads me to next question:- there are so many frameworks, tools and patterns out there. I got involved in one open source project in Sourceforge to get an insight about open source, but had to drop out because of the pace at which people with various strengths (specialists) collaborated. I think the question is beyond which language or which database to use, but whether to use one or other framework should be used for connection pooling, authentication, logging and almost all aspects of programming. It is hard to know what is out there in the first place, so unless you are a specialist how will you choose what to use instead of resorting to old barbarian ways?
On a non-technical note – it is fun to attend such meetings. First objective is to shake out of routine to see what is happening out there in the world. One other interesting thing is to see the community – it was a diverse one in all shapes and sizes. There was one that looked like a cop or a wrestler, another one probably a biker, some students, some grandfathers, many with port bellies (like beer bellies, there is something called programmer bellies), many Chinese and some Indians (I seem to always take a ratio of Chinese/Japanese/Koreans Vs Indians in such gatherings – it is like a performance metric).
20% of audience had used aspect oriented programming in their projects. Compared to the demos given using Ant, JaaS, AspectJ, Sping, Log4j etc, I felt like a barbarian who still use System.out.println(“I am here..”) for debugging and Notepad for coding.
I am convinced that these tools or methodologies increase programmer productivity, code maintainability and durable design. But how many actual customers who pay for IT projects understand or even care about using these? Then again I guess it is not a choice to be made by customers, but by the programmers.
That leads me to next question:- there are so many frameworks, tools and patterns out there. I got involved in one open source project in Sourceforge to get an insight about open source, but had to drop out because of the pace at which people with various strengths (specialists) collaborated. I think the question is beyond which language or which database to use, but whether to use one or other framework should be used for connection pooling, authentication, logging and almost all aspects of programming. It is hard to know what is out there in the first place, so unless you are a specialist how will you choose what to use instead of resorting to old barbarian ways?
On a non-technical note – it is fun to attend such meetings. First objective is to shake out of routine to see what is happening out there in the world. One other interesting thing is to see the community – it was a diverse one in all shapes and sizes. There was one that looked like a cop or a wrestler, another one probably a biker, some students, some grandfathers, many with port bellies (like beer bellies, there is something called programmer bellies), many Chinese and some Indians (I seem to always take a ratio of Chinese/Japanese/Koreans Vs Indians in such gatherings – it is like a performance metric).
dream teams
I read an article in Fortune magazine about Dream Teams failing to deliver. One of the examples was US all star basketball team failing to beat Canada in Olympics. Basic problem with Dream Team is accommodating the big egos and trying to gel the team. I was thinking about the kind of team that I would like to work with. The people whom I can work with should be easy going and should be able to laugh. Even though the laughter bit sounds like a trivial thing, I have worked with people who are so uptight that I haven’t shared one joke with them throughout the project duration. It is a stifling thing to work with such guys for a long time. Work and Play need not be separate always. A vague memory of a quote I read recently goes something like this – when you cannot distinguish whether you are working or playing, you might be on to something good. Even though money and recognition are important, in my view that comes after fun. The guy working with the only objective of promotion or salary hike may not be most productive one. I may have said this before too, but once again – it is not our eastern philosophy of not expecting anything in return. I think we have to expect something in return, but that thought should enter the mind only after dealing with the task at hand with all we can give. One more comment I read somewhere recently – a question to a talent agent was, what he does do to win future clients, and his answer was - taking care of his existing clients to the best of his ability. That should sum up my thought.
I digressed a bit, but the point I wanted to make is, if the choice is entirely mine, I would work with a people who are easy going, talented (just funny is waste of time) and ethical (I have difficulty working with people who won’t give 100% at least). I sound like a girl saying, “my guy should be funny, trustworthy and rich..”
On a different note, another dream team that failed to impress is Real Madrid. Yet another dream team is going to the world cup as favorites. I feel the Brazil is almost perfect, but need to see if that becomes their nemesis. World Cup has started and I am really excited. I haven’t been able to watch a world cup to my satisfaction so far. I used to play an entire world cup tournament all by myself, in our backyard, through group stages to final when I was in school. Anyway, this is long awaited. I have been following England team for quite some time now and I will be rooting for them – even though I don’t expect them to go all the way. I have couple of favorites there – Rooney and Gerrard – couple of real brave hearts rather than just a fat purse or big ego.
June is going to be busy.
I read an article in Fortune magazine about Dream Teams failing to deliver. One of the examples was US all star basketball team failing to beat Canada in Olympics. Basic problem with Dream Team is accommodating the big egos and trying to gel the team. I was thinking about the kind of team that I would like to work with. The people whom I can work with should be easy going and should be able to laugh. Even though the laughter bit sounds like a trivial thing, I have worked with people who are so uptight that I haven’t shared one joke with them throughout the project duration. It is a stifling thing to work with such guys for a long time. Work and Play need not be separate always. A vague memory of a quote I read recently goes something like this – when you cannot distinguish whether you are working or playing, you might be on to something good. Even though money and recognition are important, in my view that comes after fun. The guy working with the only objective of promotion or salary hike may not be most productive one. I may have said this before too, but once again – it is not our eastern philosophy of not expecting anything in return. I think we have to expect something in return, but that thought should enter the mind only after dealing with the task at hand with all we can give. One more comment I read somewhere recently – a question to a talent agent was, what he does do to win future clients, and his answer was - taking care of his existing clients to the best of his ability. That should sum up my thought.
I digressed a bit, but the point I wanted to make is, if the choice is entirely mine, I would work with a people who are easy going, talented (just funny is waste of time) and ethical (I have difficulty working with people who won’t give 100% at least). I sound like a girl saying, “my guy should be funny, trustworthy and rich..”
On a different note, another dream team that failed to impress is Real Madrid. Yet another dream team is going to the world cup as favorites. I feel the Brazil is almost perfect, but need to see if that becomes their nemesis. World Cup has started and I am really excited. I haven’t been able to watch a world cup to my satisfaction so far. I used to play an entire world cup tournament all by myself, in our backyard, through group stages to final when I was in school. Anyway, this is long awaited. I have been following England team for quite some time now and I will be rooting for them – even though I don’t expect them to go all the way. I have couple of favorites there – Rooney and Gerrard – couple of real brave hearts rather than just a fat purse or big ego.
June is going to be busy.
age of software
I have been thinking about longevity of software, how it ages and eventually dies. Many of the software that was around while I was baby footing in this industry is no longer around or has come up with newer versions that resemble to the original only in name. Is it possible to write a truly magnificent piece of software that can live forever without being a recluse? If we realistically don’t expect our software to live forever, what are we doing about it?
Is it possible to design for the future in advance? Unless hit by a bus tomorrow, I can venture a fair guess about what will happen to me at most 1 year from now, not more than that. Then how can we design a piece of software to work for even 5 years. Do we even think about how many years a piece of software will be used while designing?
There is music, films, paintings and buildings that last for a really long time, but the average life of software maybe 5 years (wild guess). There are too many parameters changing in software usage. Programming languages, operating systems and hardware is still changing along with maturity of software users, competition in the market, new innovative ways to do business and systems to support it, more and more automation. Internet is becoming part of routine life. A system designed 5 years back to automate a manual process is a called a legacy system now. Sophistication of requirements increase with time – process automation was the original requirement. Now same users want analytics, modeling and personalization of systems.
Business empowerment is another theme that is driving system changes. Users won’t want IT involvement in modifying values in a list of values or adding a field to a page or creating a custom report. Combined with Sarbanes-Oxley and Change Management processes, if you force business users to submit a change request and ask them to go through a set of approvals etc to add a field to a data entry page, then it will be frustrating. On the other hand I don’t think it is possible to make a system completely configurable so that it can sustain itself. At least that is not practical if it is for use by one organization, not a full-fledged product.
What I established so far is that too many parameters change over time – business, sophistication of users and technology. It is not cost effective to create a truly flexible system for use by internal organization. It is difficult to predict future. But is there anything that can be done to extend the life of software? Couple of things comes to mind – routine checkups, constant exercise to remain healthy and accommodate changing needs. I remember something that I studied in school economics – with education, need of people change.
If a request for a similar type of change comes in 10 times a year, it is high time to make the think about a way to reduce the IT dependency in doing that. Alleviate the heartache by giving more control to users. At the same time, don’t expect to cut off IT completely – the system may become like an abandoned house and weeds may start to grow up the roof. With this, my intention is not to make a case for livelihood of IT department.
In conclusion, systems are not immortal, it will age and there should be enough nourishment to keep it going strong and keep up with the changing world.
Is it possible to design for the future in advance? Unless hit by a bus tomorrow, I can venture a fair guess about what will happen to me at most 1 year from now, not more than that. Then how can we design a piece of software to work for even 5 years. Do we even think about how many years a piece of software will be used while designing?
There is music, films, paintings and buildings that last for a really long time, but the average life of software maybe 5 years (wild guess). There are too many parameters changing in software usage. Programming languages, operating systems and hardware is still changing along with maturity of software users, competition in the market, new innovative ways to do business and systems to support it, more and more automation. Internet is becoming part of routine life. A system designed 5 years back to automate a manual process is a called a legacy system now. Sophistication of requirements increase with time – process automation was the original requirement. Now same users want analytics, modeling and personalization of systems.
Business empowerment is another theme that is driving system changes. Users won’t want IT involvement in modifying values in a list of values or adding a field to a page or creating a custom report. Combined with Sarbanes-Oxley and Change Management processes, if you force business users to submit a change request and ask them to go through a set of approvals etc to add a field to a data entry page, then it will be frustrating. On the other hand I don’t think it is possible to make a system completely configurable so that it can sustain itself. At least that is not practical if it is for use by one organization, not a full-fledged product.
What I established so far is that too many parameters change over time – business, sophistication of users and technology. It is not cost effective to create a truly flexible system for use by internal organization. It is difficult to predict future. But is there anything that can be done to extend the life of software? Couple of things comes to mind – routine checkups, constant exercise to remain healthy and accommodate changing needs. I remember something that I studied in school economics – with education, need of people change.
If a request for a similar type of change comes in 10 times a year, it is high time to make the think about a way to reduce the IT dependency in doing that. Alleviate the heartache by giving more control to users. At the same time, don’t expect to cut off IT completely – the system may become like an abandoned house and weeds may start to grow up the roof. With this, my intention is not to make a case for livelihood of IT department.
In conclusion, systems are not immortal, it will age and there should be enough nourishment to keep it going strong and keep up with the changing world.
problems and solutions
A quote on a manager’s door in my office – “Don’t come in with problems. I want solutions”. I think a beginner will go to his boss with problems and would not have thought about solutions at all. Next level is thinking about options to solve and the pros and cons in choosing any of the options before even going to the manager. You cannot expect the manager to solve every problem. Anyway the first thing he will say is “okay, I hear your problem. So what can we do about it?”, so better be prepared for that. Better yet, identify the best solution and implement and then inform the manager. You have to inform your boss anyway – if you find the problem, analyze it and fix it and nobody knows about it, still you will be on losing end since nobody will ever know how good you are. Even the next level will be anticipating problems and fixing it before it can surface.
How to take up maintenance of an existing software application?
Software development is not always about developing an exciting new application. There are situations where you need to get into application maintenance or enhance an existing application. I never thought I would write a “How to...” or “Art of...” article, but here it is. It is not in any particular order, just things that I may have done in maintenance projects.
1. Suspend judgment: - It is a universal fact that we fear or suspect the unknown. Unless we can see it, touch it and make sure that it is not dangerous, we may withdraw from things without even putting up a fight for it. There are systems developed over many years and it may seem like an uphill task to take up maintenance of such application. I like the phrase “suspend judgment” – be it meeting a new person, watching a movie, reading a book or getting to know a new application. Suspend judgment at least until you can confidently evaluate whether you like it.
2. Persistence: - Another phrase that is sticking with me is “Things Take Time” – it takes time to get to know people, I have loved some music after listening to it for tenth time. As it says, “Long term relationships take the longest time to build.” It is like a tough puzzle – you can take a shot at it, then go watch a movie, forget all about it and then come back to it. We might be pleasantly surprised to find new ways of looking at things. It is an amusing analogy to compare getting to know a person and getting to know an application. I may not be over enthusiastic about an application in the beginning and usually observe the situation carefully until I tune into the same wavelength.
3. Poke at it: - Like a kid trying out a new addition to his world, poke at the application from all possible angles. Get to know a bit from technical architecture and you apply that to understand business behind the application some more and the circle enhances itself. This need not be very structured. If you get a lot of theory on swimming like how to breathe through mouth while flapping the feet, tilt the head and continue to move forward with an effortless action, the task will look more difficult than it actually is.
4. Find ways to find things: - I think this is an important step in being self sufficient with an application. I need to know how to get into application, documents, database and servers. Give me this much information and I can slowly and steadily learn the application. If someone asks, at least I can reply, “I can check and get back to you”.
5. Dig into it: - Once you know your way around, you can go further into the maze of application. Will I have enough inspiration to do this on my own? I am basically a lazy person and I may not take the initiative to read the code just on my own. A question from somebody about the working of specific feature of the software is a good enough motivator for me – then I can go in with the single objective of finding the answer and learn a lot on the way.
6. Document it: - documentation is painful, but I have always found it easy to do it while I am enjoying the feeling of discovery. Documentation will be boring once you know it all. I write things down usually to organize my own thoughts. I used to study in an odd way during college – I used to create notes, hand written (not scribble, but properly with margins and in good handwriting), while reading about something. This was my way to cut through the clutter in textbooks. I may never refer these notes (I might be making these notes just the day before the exam), but it used to make things clear in my mind. So creating a rudimentary document for my own reference may be a way to understand things better and often you get more questions while writing down. When you have everything in your head, maybe the some of the questions get pushed to the fringe and we would just assume that somehow these things will happen, but while writing it down in black and white, you just cannot bypass these nagging questions.
7. Get your feet wet: - Yet another phrase that I carry around “we are afraid to call ourselves experts”. We are afraid to say that when the knowledge is superficial. We think we can do something and it is simple, but have never done it, so can’t say for sure that it can be done. Try to do it, you will find obstacles that you never knew existed and by solving it, you will learn a lot.
8. Talk about it: - Discussing with team members or with sometimes anyone who may listen to you is another way of validating the assumptions. Ever had a feeling that as you speak you connect dots and come up with ideas that you have never thought of before consciously?
9. Code is the ultimate truth: - Find ways to get to the code. Yet another of my catchphrases. As an aside, I think these kinds of phrases become your guiding principles in life. I might have all my assumptions and ideas about what a system does, but if I can read the code, then that is the ultimate truth about what it really does.
10. How to debug: - I see debugging as one of the perks in software development. It presents natural challenges, kind of like puzzles in daily newspaper. But to enjoy it, one should use right set of tools, know where to look and have patience to keep looking for bits that could be helpful. In maintenance mode, knowing how to debug faster is a matter of survival as well.
1. Suspend judgment: - It is a universal fact that we fear or suspect the unknown. Unless we can see it, touch it and make sure that it is not dangerous, we may withdraw from things without even putting up a fight for it. There are systems developed over many years and it may seem like an uphill task to take up maintenance of such application. I like the phrase “suspend judgment” – be it meeting a new person, watching a movie, reading a book or getting to know a new application. Suspend judgment at least until you can confidently evaluate whether you like it.
2. Persistence: - Another phrase that is sticking with me is “Things Take Time” – it takes time to get to know people, I have loved some music after listening to it for tenth time. As it says, “Long term relationships take the longest time to build.” It is like a tough puzzle – you can take a shot at it, then go watch a movie, forget all about it and then come back to it. We might be pleasantly surprised to find new ways of looking at things. It is an amusing analogy to compare getting to know a person and getting to know an application. I may not be over enthusiastic about an application in the beginning and usually observe the situation carefully until I tune into the same wavelength.
3. Poke at it: - Like a kid trying out a new addition to his world, poke at the application from all possible angles. Get to know a bit from technical architecture and you apply that to understand business behind the application some more and the circle enhances itself. This need not be very structured. If you get a lot of theory on swimming like how to breathe through mouth while flapping the feet, tilt the head and continue to move forward with an effortless action, the task will look more difficult than it actually is.
4. Find ways to find things: - I think this is an important step in being self sufficient with an application. I need to know how to get into application, documents, database and servers. Give me this much information and I can slowly and steadily learn the application. If someone asks, at least I can reply, “I can check and get back to you”.
5. Dig into it: - Once you know your way around, you can go further into the maze of application. Will I have enough inspiration to do this on my own? I am basically a lazy person and I may not take the initiative to read the code just on my own. A question from somebody about the working of specific feature of the software is a good enough motivator for me – then I can go in with the single objective of finding the answer and learn a lot on the way.
6. Document it: - documentation is painful, but I have always found it easy to do it while I am enjoying the feeling of discovery. Documentation will be boring once you know it all. I write things down usually to organize my own thoughts. I used to study in an odd way during college – I used to create notes, hand written (not scribble, but properly with margins and in good handwriting), while reading about something. This was my way to cut through the clutter in textbooks. I may never refer these notes (I might be making these notes just the day before the exam), but it used to make things clear in my mind. So creating a rudimentary document for my own reference may be a way to understand things better and often you get more questions while writing down. When you have everything in your head, maybe the some of the questions get pushed to the fringe and we would just assume that somehow these things will happen, but while writing it down in black and white, you just cannot bypass these nagging questions.
7. Get your feet wet: - Yet another phrase that I carry around “we are afraid to call ourselves experts”. We are afraid to say that when the knowledge is superficial. We think we can do something and it is simple, but have never done it, so can’t say for sure that it can be done. Try to do it, you will find obstacles that you never knew existed and by solving it, you will learn a lot.
8. Talk about it: - Discussing with team members or with sometimes anyone who may listen to you is another way of validating the assumptions. Ever had a feeling that as you speak you connect dots and come up with ideas that you have never thought of before consciously?
9. Code is the ultimate truth: - Find ways to get to the code. Yet another of my catchphrases. As an aside, I think these kinds of phrases become your guiding principles in life. I might have all my assumptions and ideas about what a system does, but if I can read the code, then that is the ultimate truth about what it really does.
10. How to debug: - I see debugging as one of the perks in software development. It presents natural challenges, kind of like puzzles in daily newspaper. But to enjoy it, one should use right set of tools, know where to look and have patience to keep looking for bits that could be helpful. In maintenance mode, knowing how to debug faster is a matter of survival as well.
dreams
Life is too short, dreams are too big, no courage to change and the result is inertia. I find dreaming more comfortable than doing something about it. Today for example, I read a piece about the coalitions in Kerala politics - it truly enraged me and they say you need passion to do something – I had all the passion at that moment. But then I thought about what I can do - maybe setup a blog, invite like minded people to collaborate, start a movement, try to open the eyes of the most literate bunch of people in India to sit up and realize that we all have something called a spine and a brain. But no, like all other mallus, I am also not going to anything about it. I can just hope that all our leaders will perish and leaders of the next generation will at least be from a different family.
Another one of my recurring dreams is of starting a company, a small one. I have this dream often while coming out of office in the afternoon for lunch. It is spring, getting greener by the minute and sunshine feels good. If I have my own company, maybe I can work in jeans and T Shirt, sitting on a park bench or somewhere, instead of sitting in a claustrophobic cubicle under artificial light all day. I even wrote down product ideas, read a book on startups, tracked small business blogs using RSS feeds, got to know of terms like ISVs, bootstrap etc. Then it remained just that – a recurring dream.
Why don't we have enough courage to take up on the dreams? I find satisfaction in blaming it on the culture of following rather than leading, laziness and multitude of similar things.
Life is too short, dreams are too big, no courage to change and the result is inertia. I find dreaming more comfortable than doing something about it. Today for example, I read a piece about the coalitions in Kerala politics - it truly enraged me and they say you need passion to do something – I had all the passion at that moment. But then I thought about what I can do - maybe setup a blog, invite like minded people to collaborate, start a movement, try to open the eyes of the most literate bunch of people in India to sit up and realize that we all have something called a spine and a brain. But no, like all other mallus, I am also not going to anything about it. I can just hope that all our leaders will perish and leaders of the next generation will at least be from a different family.
Another one of my recurring dreams is of starting a company, a small one. I have this dream often while coming out of office in the afternoon for lunch. It is spring, getting greener by the minute and sunshine feels good. If I have my own company, maybe I can work in jeans and T Shirt, sitting on a park bench or somewhere, instead of sitting in a claustrophobic cubicle under artificial light all day. I even wrote down product ideas, read a book on startups, tracked small business blogs using RSS feeds, got to know of terms like ISVs, bootstrap etc. Then it remained just that – a recurring dream.
Why don't we have enough courage to take up on the dreams? I find satisfaction in blaming it on the culture of following rather than leading, laziness and multitude of similar things.
hibernate
Winter is still going strong and I am sort of hibernating all through it. Everything seems to be going in slow motion. I am literally playing the waiting game on many things. It is like those horoscopes predicting that it is not good until some particular time and I seem to have suspended activity until then.
By the way, second anniversary of my blog has passed and the pauses are getting longer. I sometimes feel that even my interest in blogging has changed somewhat. How long is it possible to write something interesting in a blog that is not about anything specific? After some time, like a child growing up, the thoughts become repetitive and established – there is nothing new to offer. If there is no disturbance or change – good or bad, life as well as blog may have nothing different to say. Many of the blogs that I used to read when I started this, have closed down and some of the persistent ones do not have the fresh perspective that attracted me to it in the beginning. I have become used to them and I know what to expect. Even some of the topical blogs that I read gets too thin with time, like trying to extract a little more juice out of a limp lemon. But then how long can there be change enough to make life interesting and not feel that you are aging or slowing down?
One of my colleagues was telling me the other day that everyone in his age group is now married and having kids – so every other weekend for more than one year, he is either attending a baby shower or attending a kid’s birthday party and finally it is dawning to him that he is no longer as young as he thinks he is. I think with age laziness increases, fat creeps into mind and body and we settle in for the long haul of life to take its course. That is scary along with the fact that my thirties is not very far. I am waiting for this winter to get over and hopefully there will be changes to my routines by summer.
Winter is still going strong and I am sort of hibernating all through it. Everything seems to be going in slow motion. I am literally playing the waiting game on many things. It is like those horoscopes predicting that it is not good until some particular time and I seem to have suspended activity until then.
By the way, second anniversary of my blog has passed and the pauses are getting longer. I sometimes feel that even my interest in blogging has changed somewhat. How long is it possible to write something interesting in a blog that is not about anything specific? After some time, like a child growing up, the thoughts become repetitive and established – there is nothing new to offer. If there is no disturbance or change – good or bad, life as well as blog may have nothing different to say. Many of the blogs that I used to read when I started this, have closed down and some of the persistent ones do not have the fresh perspective that attracted me to it in the beginning. I have become used to them and I know what to expect. Even some of the topical blogs that I read gets too thin with time, like trying to extract a little more juice out of a limp lemon. But then how long can there be change enough to make life interesting and not feel that you are aging or slowing down?
One of my colleagues was telling me the other day that everyone in his age group is now married and having kids – so every other weekend for more than one year, he is either attending a baby shower or attending a kid’s birthday party and finally it is dawning to him that he is no longer as young as he thinks he is. I think with age laziness increases, fat creeps into mind and body and we settle in for the long haul of life to take its course. That is scary along with the fact that my thirties is not very far. I am waiting for this winter to get over and hopefully there will be changes to my routines by summer.
Top Coder
I came across TopCoder, a site for conducting coding competitions. It is a nice idea to get rated against other programmers and improve the skills. Programming on the job is mostly routine and repetitive for most application development scenarios and standard algorithms are almost never used. This will make sure that we don't forget the fundamentals and with time the routine programs will also get better - develop an eye for better processing, efficiency and performance. What I would like to believe is any activity that is even tingling the brain will add some value directly or indirectly to work - something like regular exercise to keep us healthy.
I was curious about any presence of Indians in this. There are thousands of programmers from India and some very good universities, but I didn’t find the country or any university from India featured in the list. This is just confirming my suspicion that we are better in following than leading. Or it could be just that this is not yet known to our brilliant programmers or all the Indian developers are 110% immersed in the work that nobody has time for things like this.
Anyways I am planning to attempt and get a rating sometime to see where I stand.
I was curious about any presence of Indians in this. There are thousands of programmers from India and some very good universities, but I didn’t find the country or any university from India featured in the list. This is just confirming my suspicion that we are better in following than leading. Or it could be just that this is not yet known to our brilliant programmers or all the Indian developers are 110% immersed in the work that nobody has time for things like this.
Anyways I am planning to attempt and get a rating sometime to see where I stand.
Subscribe to:
Posts (Atom)