The deadline handlers in software development

coffee_compDuring my stint in the IT industry I have seen developers with diverse deadline handling styles. Following are the broad categories I have noticed till date:

1. Learns first and fast, implements faster: These are the guys who are mostly driven by a passion to learn, finish things well within the deadline and get rid of the pressure. They always tend to pay more (in measures of effort and tension) than what it’s worth and forget it. In most cases this lot will finish the task, think of loopholes, possible future enhancements, enhance it, test thoroughly and let it go well ahead of the deadline. Even testers like to work with these developers as they find solutions to intermittent issues fast and try to find solutions to fix the issues instead of turning bugs into features. They have a penchant for perfection in whatever they do and they are definitely difficult to work with (as fellow developers) because they are the fastest and don’t tolerate sloth when there is a way. The problem with this group is that they end up in taking more workload to balance the lag of the snails and time-thieves in the team when they should have had some free time. They are prone to bouts of frustration but they bounce back due to their passion.

2. Always exactly on time: These engineers take it steadily. They don’t give in to undue/extra pressure or passion and build up through time to complete the task on the deadline. It is a delight to work with these engineers in the team. They are technically capable and know how to maintain a great work-life balance. They are more in control of their time than the first category. Most of the time they follow office timings to the letter. When the first category despairs, this group simply moves on. This group is also reasonably receptive, temperamental and are ready to approach the first category for solutions when stuck. I believe they are more matured professionals than any other category I discuss here. They make much better and balanced managers as well.

3. The time-wasters: This is a dangerous and deceptive set to handle. Their only goal is to drag even mundane tasks by adding undue weight to it irrespective of whether they are capable of doing it within time or not. And in cases where they really aren’t they simply wreck havoc by wasting others’ time in discussions, unrelated/unforeseen problem reports (which most of the time can be dealt with easily), trying to dump issues on others as side-effects of their changes and asking for more resource, often after crossing the deadline. This group also has a tendency to pick issues in others’ tasks like a tester but are reluctant to think on solutions to those and project themselves as more vocal and know-alls in front of the management. Technically they range from average to poor. But managers are often impressed by their projections instead of their deliverables. This group reminds me of a person trying to move with his ass intentionally buried in thick mud while others are avoiding the same patch.

4. The time-handicapped: These are the wrong people in the wrong place. They will unintentionally waste others’ time and often won’t be able to deliver until much beyond the deadline. The code is more like a maze to them and they are also afraid of it, which is the worst part. As any team is a mixture of individual capabilities they are a reality and the other team members take a lot of responsibility in making this group a functional part of the team. It’s not always true that this group is sub-average, sometimes it is due to falling in a totally different domain, huge module exposure for the first time, fear of code etc. In any case, they are less dangerous than the third category because the manager’s expectation already lies low with them. If hardworking and willing to learn, I have often seen considerable improvement in this group in the continuous line of working with the stronger teammates.

Just to add to this, I have seen an interesting class of managers whom I termed “trump card holders”. They have an additional advantage that their teams have a few guys who are technically very strong and capable of handling anything. These managers take the advantage of this and will keep themselves at a safe distance from the technicalities or complexities involved in the regular tasks his developers are doing. They use the talents in their team as the last line of defense when things go haywire. Though this doesn’t result in a good effort balance in the team and most of the time the weaklings take advantage of it at the cost of their own technical standstill, it is still a strategy which works!

Which programming language to start with?

hacker_compThis is an eternal question dug over and over during engineering graduation days. IMHO, it’s best to start with C. It is a very rich language and is more powerful than any other non-obscure 😉 programming language ever written. Many other programming languages are written based on C. It is not very difficult to learn new programming languages when you already are well-versed in one. In my personal experience, I studied for 15 days and scored 98% in SCJP then conducted by SUN Microsystems. I haven’t worked regularly in JAVA since 5 years but even today it doesn’t block me from looking into a piece of JAVA code or reviewing them. The truth is – learning a language doesn’t matter if you know only the syntax and features of the language, a complete understanding of how to convert any logic into that language in the best possible way is required. It takes minimum 6 years for a good programmer to claim that he knows C (or any other language) well. One more point to remember here is – if you are interested in systems programming it’s better to marry C ;); C++, JAVA etc. are engineered more towards customer requirement oriented rapid application development. I mean business, not elegance.

What it takes not to lose technical focus in the IT industry

coffee_compMost computer engineers dream of becoming software wizards during graduation. But when they enter the Indian IT industry they lose focus in a few years and become another programmer in the herd. What does it take to step aside from the crowd and walk towards your own goal? From my personal experience, watching seniors and juniors around me I have found a few guidelines very very essential to keep a software engineer focused.

1. Many a time a meager salary dejects a quality developer. The trick is to go for successive switches within a span of a few years. An employee’s relationship with his company is strictly business – the one which can afford you gets your service. There’s a myth that quick switches may be regarded negatively by companies. Well NO! What matters is your quality and capability of getting their work done. No company wants to pay an employee over the next 3 decades without knowing beforehand whether it will have suitable work for him all the time. But as a professional it’s ethical to complete the current project and then leave if it is in a critical state. Once you cross a lakh INR per month net salary in India it’s time to stabilize. Better to do it sooner not to worry about money later. I left 3 companies in 5 years before joining my current company which suits me with respect to work, work culture, salary and I never regret the past switches a second.

2. If the work is not quality, there’s time to spare and no good openings in sight it’s the time to enhance your skills. Join any open-source module of your interest, contribute and sharpen your weapons. It matters a lot in your CV. It takes at least 6/7 years to become a confident developer unless you are a genius or a prodigy; being well-versed C, C++ or JAVA is simply the beginning. In addition, there are much more opportunities to learn in product based companies than the service based companies. If you are a quick learner, exploring multiple domains makes you formidable.

3. The wrong boss who gives more importance to people who are technically handicapped and sound more. Personally, I have seen this a lot but passion for work can keep you going. People take credit for things others have done, the wrong person gets appreciated all the time… But a focused developer with a few years experience can survive these and have his satisfaction from his work and obviously a better package than others (check point 1). Appreciation from the wrong people doesn’t count – pure and simple (rather pity them because they can’t understand complexity). But this does affect freshers extremely and finding a positive mentor is the only option for them.

4. Read and realize the Tao of Programming. It teaches how to live beyond everything and in your own technical mind-space. It may seem funny or trivial (to know-all people at least) but it is nothing less that a full-scale Bible – it teaches to forget everything in honest hard work.

Here’s my favourite one from the Tao:

A programmer from a very large computer company went to a software conference and then returned to report to his manager, saying: “What sort of programmers work for other companies? They behaved badly and were unconcerned with appearances. Their hair was long and unkempt and their clothes were wrinkled and old. They crashed our hospitality suite and they made rude noises during my presentation.”

The manager said: “I should have never sent you to the conference. Those programmers live beyond the physical world. They consider life absurd, an accidental coincidence. They come and go without knowing limitations. Without a care, they live only for their programs. Why should they bother with social conventions?

“They are alive within the Tao.”

“Never Go back” by Evanescence booming through my ears in full volume and 4:14 in the morning, it’s time for me to sleep. Analyzed an issue related to a nasty kernel crash on SMP systems today (no yesterday) – satisfaction guaranteed. 😉

New programming slangs

cool_penguin_smallA collection of exotic new expressions for regularly faced situations. For example, last week I had to tell a 5-yr experienced developer to RTFM when he dragged me to his desk to ask why the files from his test rpm are not able to overwrite the ones from the already installed package and is throwing conflict messages. Once I read a manager fired his developer because he did not know how to redirect a program’s error messages from the console to a file.

I loved the “Drug Report” and “Fear Driven Development” most. How about you?