Monday 1 December 2014

Problems with software coders in India.


We don't often think about coding tricks but it's comes into picture when you are no more into a

project and new guys come into it and need to understand the system. You are no where and it

depends on your coding style that whether they are jumping into an ocean or a little pool. Depth

should be in implementation not in complexity of the code, it's not about showing off how much you

know but it's important how much you are able to make the readers understand your code what

you tried to do. Let us assume that there are no documentation about what is stuff you have done,

now the psychology that's comes into  play about coders as per my experience is that they are more

concerned about showing of their knowledge rather than making it simple as if they are on to a

eligibility test with newbies. It's really seems to be a foolishness or stupidity to do such things.
         

  As per my experience I have worked in very few fresh project and most of them are existing

application and making the situation HELL like. In maximum case I didn't found any comment about

what stuff is fed into the system. Comments are missing, approach to a problem is such that you are

writing program for some microchips or space science when the actual program is for some simple

calculation of some say debit - credit. And this goes on with every new programmers come into the

system making it a disaster day by day.

So a proper convention for writing code is required  and that convention is not only to follow a proper

structure of coding but also make a coding simpler to understand where the approach will be not to

SHOW OFF you SKILL but to make the process smooth as well make it as simple and

understandable with proper comments and documentation.

And to add to this there is a lot to think about coding convention which is an essential part of coding.

Coding convention is definitely necessary but conventions should have the freedom for amendment

based on situations which actually does not happen and project leaders are found to be biased and

follow strictly some conventions which might be build when the system designed and following the

same thing after a decade. Developer should be given freedom and flexibility which will of course

make a system readable and understandable.

Good coder does not mean good developer.

Coding is not a big deal in any language but all it matters is a proper and thorough understanding of the existing system whether it is computer based or manual. It's not rocket science indeed. It's all about understanding user requirement. The main problem with coders is that whenever they got into studying about the requirements they immediately starts thinking about how they should be coding it. It's a very wrong way to think, because coding depends on requirements not the system depends on coding. If you have a proper understanding of the system requirements coding is not a big deal.
    Another problem with developers is when they started thinking that their code can never be wrong, ok so is it!. So you should be siting above GOD, because even GOD's creation have a lots of flaws. Jokes apart never try to rectify users rather rectify yourself, learn from your mistakes. It's not important what user wants, it's important the problem they face with their job and the interface they work with. User can never always say what problem they face, circumstances of their problems may be fragmented, but you have to accumulate all their problems and their requirements to design the system . Remember it's not about how well you code but it's about how well you understand the system.
Let us take an example. Suppose user needs to upgrade employee salary periodically after every six months for a particular rate. Now he has to do this manually fetching every record one by one. Now automation is required. But there are some issues. Date for increment is not fixed but lies within a range. So you can create a notification asking user to run the update process within the date range and also give freedom to user about stopping the notification on his system and when he stop the notification an email might be send to him notifying that updation is not done. If it is a top priority even you can block any operation in the system on the last day of such updation until process is done. That is it does not only depends on users choice only but also to the whole system and it's job priority. Now the question is about if the rate of increment varies. Increment rate can be categorised into employee grade or group or designation and can also be employee wise for any special case. So you cannot be biased when designing the system. User will never conform itself for the system, system needs to be designed as such to understand the user. I hard many designers or coders that system is such so you need to follow it, it's totally wrong because what happens in that case that system is designed at the will of the designer but when problems are faced later on system need to be modified in AD-HOC method which turns it into a hotchpotch and it's slowly started becoming complex one, not in the sense of performance but in the sense of poor designing.
And last but not the least. Every system when designed needs a proper documentation. Why?. Does anyone guarantees that he or she will stay with the system for lifetime? no of course so proper knowledge transfer is necessary and that is possible with your documentation about the system. And in that case you should take help of a technical writer because it's not necessary that if you are good programmer you can be a good technical content writer. You can learn a whole lot of books about designing but all that matters is your real life interaction.